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Einordnung und Softwareunterstützung von interaktiven 
Arbeitsmeisen im Terminalkabinett innerhalb der Grund- 
ausbildung Informationsverarbeitung 


1, Ausgangspunkt und Zielbestimmung 

Für das Lehrgebiet Informationsverarbeitung (IV) wird im 
Lehrprogramn für die Ausbildung in Technischen Wissenschaften 
els wosentliche Zielstellung formuliert s 

"Der Student wird befähigt, für die Lösung einfacher Aufgaben 
seines Fachgebietes Algorithmen selbständig aufzustellen, 
mittels einer problemorientierten Sprache daraus ein funktions- 
fähiges Programm zu formulieren, dieses unter Nutzung der 
Hilfsmittel eines leistungsfähigen Betriebssystems zu testen 
und die bei der Abarbeitung desselben erzielten Ergebnisse 

zu analysieren.” 


Die geforderte Selbständigkeit im Umgang mit einem leistungs- 
fähigen Betriebssystem konnte durch den früher praktizierten 
closed-job-Betrieb nur teilweise erreicht werden, Auch das 
danach an der Ingenisurhochschule Zwickau am KRS 4201 durch- 
geführte Praktikum brachte für den Lehrabschnitt Betriebs- 
eyeteme kaum eine effektive Untermauerung, jedoch wurde 
durch den unmittelbaren Rechnerkontakt eine Motivierung 

der Studenten erreicht. 

Ziel der interaktiven Arbeitsweise ist es, die Studenten. 
neben den erforderlichen theoretischen Kenntnissen mit aus- 
reichenden praktischen Erfahrungen auszustatten und sie zu 
motivieren, selbständig im weiteren Studienverlauf und in 
der Praxis das Rationalisierungsmittel Rechentechnik einzu- 
setzen, 

Dieses Ziel kann nur erreicht werden, wenn die IV-Grundaus- 
bildung im Studium so zeitig wie möglich beginnt und über 
den gesamten Verlauf dieser Ausbildung durch häufigen 
Rechnerkontakt eine routinemäßige Handhabung der Rechen- 
technik erreicht wird. 
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Eine Erziehung zu Gewissenhaftigkeit, Zielstrebigkeit 
und Ausdauer wird durch die auftretenden Erfolgserleb- 
nisse unterstützt, 


2, Einordnung in die Seminarführung 

Für einen frühzeitigen Rechnerkontakt sind im Prinzip 
Kenntnisse zur Hard- und Software des Rechners erforder- 
lich, 

Ale Strukturträger der Grundausbildung Informationsverar- 
beitung können 


Hardware 
Systemsoftware -——» Anmendersoftnare 


angegeben werden, ; 

Die Entwicklung von Softmwarelösungen bildet den Schwerpunkt 

der Ausbildung. Es geht dabei nicht nur um eins Algorith- 

mierung und Programmierung schlechthin, sondern un die 

Lehre einer Problemlösungsmethodik, Diese Methodik wird in 

Vorlesungen und Seminaren angenendet. Folgende Entmurfs- 

hilfsmittel werden genutzts 

- Strukturübersicht und Obersichtsdiagramne von HIPO 

- strukturierter Leitlinien-PAP mit den Struktur- 
elementen Sequenz, Alternative und Zyklus 

- strukturierte Programmierung 

- Programmentwicklung im Dialog. 

In folgenden Abschnitt geht es um die Frage, nie die orsten 

Terminalsitzungen in die Seminarführung integriert werden, 

Das dritte Seminar wird im Rechentechnischen Kabinett 

durchgeführt. Zur Vorbereitung dieser ersten Terninal- 

sitzung stehen in der Regel zwei Vorlesungen und znei 

Seminare zur Verfügung, 

Diese werden genutzt, um neben einer kurzen Einführung den 

prinzipiellen Aufbau und die Arbeitsweise einer EDVA, die 

Problemlösungsschritte bei der Erarbeitung eines EDV- 

Projektes und die Komponenten eines Betriebssystems grob 

zu skizzieren. Innerhalb der zweiten Vorlesung wird an- 
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nand eines linsaren FORTRAN-Programmes mit der problen- 
orientierten Programmierung begonnen, 

Die ersten beiden Seminare dienen dazu, an einen linearen 
Programm alle Problenlösungsschritte zu absolvieren bzw, 
zu erläutern, Ale Darstellungsmittel werden das HIPO- 
Obersichtsdiagranm und der strukturierte PAP genutzt, An- 
hand eines groben Datenflußplanes werden den Studenten 

die Technologie der Programmentwicklung im Dialog vorge- 
stellt und das Dateikonzept erläutert. 

Ein Arbeitsmaterial wird zur Vorbereitung auf das dritte 
Seminar ausgehändigt. Es enthält nur die wesentlichsten 
Konnandos und Schalter zu MCR, PIP, EDI, FOR und TKB, 

Das Ziel der ersten Terminalsitzung ist es, die Studenten 
zu befähigen, ‚selbständig den Rechner zur Quelltexteingabe 
und -korrektur sowie zur Arbeit mit dem Anmendersystenm zu 
befähigen. 

Es werden folgende Kommandos bzw, Dienstprogramme genutzt: 
HEL, FLI, EDI, PIP, STA,@ RETTEN und BYE. Den Schwerpunkt 
bildat die Nutzung des Editore (EDI) zur Korrektur einer 
vorgefertigten Textdatei, Nach diesen Seminar sind 1, 
Selbstetudium die Annenderseystemkomponenten zur Binführung 
in FORTRAN zu nutzen. Außerdem kann der Student mit Hilfe 
eines "Leistungskontrollprogramms" zu arithmetischen Aus- 
drücken sein Wiesen überprüfen, Ebenso ist der Tisch- 
rechnermodus (BAS) nutzbar, 

Das vierte und fünfte Seminar werden eingesetzt, un die 
‘Problemlösungsschritte bis einschließlich der Programmierung 
an linearen und verzweigten Programmen zu üben. Die 

dritte Vorlesung schafft dazu die Voraussetzungen, j 

Ia sechsten Seminar werden anhand des 'Datenflußplanes aus 
dem zweiten Seminar alle Schritte der Programmentwicklung 
in Dialog am Rechner von den Studenten absolviert, Dabei 
werden genützt: EDI, FOR bzu,@ FELT, TKB und RUN, 

Danach hat jeder Student an einem einfachen Beispiel alle 
Schritte. der Problemlösung einschließlich des Rochnertest 


und der Analyse der Ergebnisse selbst durchgeführt. 
Ausgehend von dem dadurch gewonnenen Verständis für: den 


n 
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Problemlösungsprozeß, werden die einzelnen Problem- 
lösungsschritte in den folgenden Lehrveranstaltungen 
näher erläutert und an Beispielen geübt, 


3. Software für die Unterstützung interaktiver Ar- 
beitsweisen 


3,1, Ausgangssituation und Zielstellung 


Bei Aufnahme der Arbeiten im Jahre 1983 als Einsatzvorbe- 
reitung für den Nachfolgerechner des R300 (K 1630 oder 

CM 4-20) stand nachnutzbare Software, die auch Möglich- 
keiten von RGU (CAT) beinhaltet, nicht zur Verfügung. 
Entwicklungen für SKR waren nicht geplant und der für 
ESER geplante Import von RGU-Software aus der UdSSR war 
für uns nicht relawänt, Die Qualifizierung unserer Aus- 
bildung verlangte jedoch einen schnellen Einsatz aus- _ 
bildungsspezifischer Software. Die Entwicklungsarbeiten 
erfolgten auf einem K 1620. Mit Installation einer CM 4-20 
im Jahre 1984 wurde die entwickelte Software auf diese. 
übernommen und mit Beginn des Studienjahres 1984/85 in der 
Lehre eingesetzt, 

Die Arbeiten an einen terminalorientierten interaktiven 
Praktikumssystem (TIPS) zielten zunächst auf eine Unter- 
stützung des Lernenden und Lehrenden bei der Durchführung 
von Praktika, Die rege Nutzung des Rechners im Selbst- 
studium und die damit verbundenen Probleme für den ler- 
nenden Nutzer führten zur Zielstellung, diesen durch ein 
Anwendersystem /1/ zu unterstützen. D. h, in diesem An- 
wendersystem müssen Auskunfts- und Informationsmodus, Pro- 


grammentwicklungsmodus, Tischerrechnermodus und die Ab- 
arbeitung lauffähiger Objekte enthalten sein, 

Der Informationsmodus ist so konzipiert, daß mit ihm auch 
rechnergestütztes Lernen, Abarbeitung von Leistungskon- 
trollen und Erstellung von sequentiellen Dateien erfolgen 
kann, 

Eine Individualisierung der Dialogführung soll durch die 
wahlweise Nutzung der Menü-Technik oder von Kommandos 
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möglich sein, Das System wurde modular konzipiert und 
bei der Realisierung einzelner Komponenten achteten wir 
auf ihre Nachnutzbarkeit, 


3.2. Unterstützung der Arbeit des Nutzers (des Studenten) “ 
durch das _Programmpaket DIRAS_ 72/ 


Der selbständig arbeitende, jedoch durch das Anwendersystem 
geführte Student wird durch das den Dialog rechnerseitig 
führende Programm DIRAS in seiner Arbeit unterstützt. Dabei 
entnimmt das vom Unterrichtegegenstand unabhängige Pro- 
grann DIRAS Textinformationen aus einer Direktzugriffedatei 
und gibt diese auf Bildschirm aus, 
Eine solche auszugebende Einheit von Textinformationen, 
deren Empfang vom Teilnehmer mit einer Eingabe bzw, Tasten- 
druck quittiert werden muß, wird nachfolgend Bild genannt, 
Intern ist die Gesamtheit aller Bilder mit gemeinsamen Sach- 
bezug in einer Direktzugriffedatei abgespeichert, Eine 
solche Direktzugriffedatei ist also die interne Form eines 
Lehrprogramnmes, 
Da sich Bildfolgen, die die Arbeit des Teilnehmers ledig- 
lich lenken, in ihrer internen Darstellung nicht von echten 
Lehrprogrammen unterscheiden, werden sie nachfolgend etwas 
ungenau ebenfalls ale Lehrprogramm bezeichnet, Vom Start 
von DIRAS an bis zur Beendigung des Programmlaufs kann der 
Teilnehmer nacheinander in mehreren Lehrprogrammen arbeiten, 
Durch die gegebene oder unterlassene Antwort entscheidet 
sich der Teilnehmer für genau eine aus maximal 13 ver- 
schiedenen Fortsetzungsmöglichkeiten, d. h, die vom Teil- 
nehmer gegebene Autnwort (die in Kurzform gegeben werden 
darf), wird verglichen mit maximal 13 zu jedem Bild angeb- 
baren Antwortvorgaben des Autors, Dabei kann der Autor 
folgende Fortsetzungsarten als Folge einer bestimmten Ant- 
wort veranlassen: 

- Wechsel zu einem bestimmten Bild desselben Lehr- 

programmes 
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- Nochmaliges Anzeigen des gleichen Bildes (2. B. 
nach unsinnigen Antworten) 

- Wechsel zu einem von drei Nachfolgebildern in Ab- 
hängigkeit von den bisher im Sitzungsverlauf vom 
Nutzer erwiesenen Fähigkeiten 2 : 

- Ausgabe einer Bewertung der Arbeit des Nutzers und 
Fortsetzung mit einem bestimmten Bild desselben 
Lehrprogrammes 

- Übergang in die PAUSE-Anweisung, wodurch zwischen- 
zeitliche Arbeit des Nutzers in anderen Programmen 
möglich wird 

- Wechsel zu einem bestimmten Bild eines anderen Lehr- 
programmes (Schließen der Direktzugriffsdatei und 
Eröffnen einer anderen Direktzugriffsdatei) 


Während der Nutzer entsprechend dem vom Autor festgesetzten 
Menü antwortet, werden implizit für den Nutzer die darge- 
stellten Handlungen ausgeführt. Die eingangs dargestellten 
Arbeitsmodi des Anwendersystems werden durch DIRAS auf 
folgende Weise realisiert: 


e der Informationsmodus 
durch bloße Dialogführung mittels einer oder 
mehrerer Direktzugriffsdateien 


« der Leistungskontrollmodus 
durch Dialogführung und Registrierung des 
Erreichens bestimmter Bilder, 
Diese Kennzeichnungen werden klassifiziert‘; 
eine Klasse "richtig", mehrere Klassen "falsch" 


der Dateierstellungsmodus ; 
Dialogführung „ wobei manche Antworten des 
Teilnehmers in einer sequentiellen Datei 
gesammelt werden, 
Diese kann später ale Eingabedatei eines an- 
deren Programmes verwendet werden 
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« der Tischrechnermodus 
Er wird lediglich unterstützt: Die benötigten 
Kommandos für den BASIC-Interpreter werden dem 
Teilnehmer vorgestellt, danach geht DIRAS in 
eine PAUSE über, Nach erfolgter Arbeit mit BASIC 
wird die Arbeit im Programm DIRAS wieder aufge- 
nommen. 


» der Programmentwicklungsmodus 
Er wird lediglich unterstützt: Der Werdegang 
eines FORTRAN-Programmes wird vorgestellt, 
Erforderliche Kommandos werden auf Bildschirm 
ausgegeben, Jeweils nach der Darstellung eines 
Kommandos geht DIRAS in eine PAUSE-Anweisung 
über, Das dargestellte Kommando kann sofort, 
d. h. solange das Bild noch sichtbar ist, in die 
Rechenanlage. eingegeben werden. Durch den Dialog 
wird der Student bis zum Start des arbeitsfähigen 
Programmes geführt, 


« Nutzung anderer Programme und Dienstprogramme (Operatoren) 
Die Arbeitsweise ist hier die gleiche, die An- 
leitung erfolgt über ein DIRAS-Lehrprogramnm, 
nach PAUSE oder Stop können die Handlungen vom 
Teilnehmer ausgeführt werden, 


/ Wie sieht nun die Arbeit des Teilnehmers im Anwendersystem 
aus? 
Durch Eingabe von START wird das unter diesem Namen in- 
stallierte Programm DIRAS gestartet. Es werden einige per- 
sönliche Angaben des Teilnehmers (Name, Seminargruppe) an- 
gefordert, Danach wird ein bestimmtes Lehrprogramm ange- 
steuert, in dem auf weitere Programme verwiesen wird, 
Die Einzelbilder erscheinen je nach Maßgabe des Autors vom 
oberen Rand des Bildschirmes an oder als Fortsetzung eines 
bereits sichtbaren Bildes, Bei ungültigen Antworten or- 
scheint ein vom Autor für diesen Fall zugeordnetes Nach- 
folgebild oder dasselbe Bild noch einmal. i 
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In vom Autor festgelegten Fällen können die Antworten 
als Zahl gedeutet werden, 
Die Eingebe muß in einer üblichen Darstellung erfolgen, 
Der Teilnehmer ist an keinen Zahlentyp gebunden, Solche 
Antworten werden bezüglich der Relationen > , a oder < 
mit den vom Autor notierten Vorgaben verglichen (Beispiels 
hat der Autor Z#> 1@1 notiert, gelten alle Teilnehnsrant- 
worten richtig, deren Wert größer als 1@1 ist). Für nicht 
interpretierbare Zahlendarstellungen des Teilnehners wer- 
den spezielle Fehlermeldungen erzeugt, die Antwort gilt 
dann ihrem Werte nach als falsch, Warnungen weisen darauf 
hin, daß "bedenkliche Darstellungen vom Programm abge- 
ändert wurden. Auch bei unsinnigen Antworten ist kein 
"Absturz” des Programmes zu befürchten, 


Unabhängig von den vom Autor vorgesehenen Antworten kann 
der Teilnehmer an beliebiger Stelle durch Eingabe reser- 
vierter Antworten folgende Handlungen erreichen: 
- Rückverfolgung des Dialogs in einem Lehrprogramm 
es können alle bisher. gesehenen Bilder des Lehr- 
programms und das Anfangsbild des Lehrprogramnes 
gerufen werden, in dem der Teilnehmer gerade ar- 
beitet | 
- Abbruch des Dialogs 
- Einleitung der Direktanwahl von Bildern 
Es können maximal 40 Bilder jedes Lehrprogramnmes 
mit Namen versehen werden, 
Unabhängig vom bisher beschrittenen Dialog lassen 
sich diese Bilder vom Teilnehmer direkt anwählen, 
ohne daß er das gesamte dorthin führende Frage- 
Antwort-Spiel durchführen muß, 
Dieser Prozeß ist vom Autor durch Bekanntgabe sei- 
ner Verzeichnisse als Bildfolge zu unterstützen, 
Die drei letztgenannten Möglichkeiten existieren im Datei- 
erstellungsmodus und im Leistungskontrollmodus nicht, da- 
mit z. B. nach Erläuterung der Aufgabenlösung Teile der 
Leistungskontrollen nicht noch einmal durchlaufen werden 
können. Durch das Leistungskontrollabschlußbild (Be- 
wertung) werden die Einschränkungen wieder aufgehoben, 
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Um ein Lehrprogramm für DIRAS zu erzeugen, muß der 
Lehrer (Autor) die einzelnen Bilder umgangssprachlich 
notieren, Die Notation ist durch Kopfzeilen zu ergänzen, 
In diesen stehen Bildnummer, bei direkt anwählbaren Bildern 
der Bildname, die Antwortvorgaben und die zugehörigen 
Bildnummern der Nachfolgebilder, 
Die Notation wird von einem Programm übernommen und in 
die Direktzugriffsdatei eingegliedert, Änderung von Bild- 
texten geschieht durch Neueintragung des geänderten Textes. 
Ein Reorganisationsprogramm sorgt dafür, daß nicht mehr 
gültige Bildtexte in der Datei durch neu hinzukommende 
Bildtexte überschrieben werden, 


das Programmpaket DPG /3/ 


DPG wurde in rd 10/84 bereits beschrieben, Mit einem auto- 
matisch generierten Programm von DPG kann der Teilriehmer 
genauso arbeiten wie mit einem Lehrprogramm im System DIRAS, 
Da aus einem Lehrprogramm von DPG immer eine Task erzeugt 
wird, ist ein Wechsel von einem Lehrprogramm in ein anderes 
jedoch nicht möglich, 

Automatisch mit DPG erzeugte Dialogunterprogranme können mit 
handgeschriebenen Verarbeitungsmoduln zu arbeitsfähigen 
Programmen verbunden werden, Die Eingabe von Zahlenwerten 
an COMMONvariable ist durch den Teilnehmer am Ende jedes 
beliebigen Bildes möglich, 

DPG besteht aus einem Bildunterprogrammgenerator, einem 
Hauptprogrammgenerator und einem Generator für die Zzuge- 
hörige Oberlagerungsbeschreibungsdatei sowie aus ver- 
schiedenen Objektmoduln. Der Dialogteil ist ähnlich wie bei 
DIRAS umgangssprachlich zu notieren, 


das Programm FELI /4 


Das für die Arbeit im Rechentechnischen Kabinett einge- 
setzte Kommandoprogramm FELI, welches mit einer Task gleichen 
Namens zusammenarbeitet, bereitet die vom FORTRAN-Compiler 
FOR erzeugten Übersetzungsprotokolle für die Ausgabe auf 
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Bildschirm vor und gibt diese auf Bildschirm aus, 
Dabei werden die Fehlermeldungen des Compilers durch 
deutschsprachige Erläuterungen bzw. Vermutungen über die 
Fehlerursache ergänzt, so daß der Student die dargestellten 
Sachverhalte an den sichtbaren Programmzeilen überprüfen 
kann, 
Fehlermeldungen, die in den Übersetzungsprotokollen erst 
unter den Programmtexten erscheinen (mit Verweis auf die 
Zeile, in der der Fehler bemerkt wird), werden in den Text 
an die entsprechende Zeile eingestreut, so daß fehlerhafte 
Zeile und Fehlergeldung gleichzeitig auf Bildschirm sicht- 
bar sind. Das Anschauen der Programme am Bildschirm der 
CM 4-20 wird durch das Dienstprogramm FLI erleichtert, 
welches das Rollen des Textes auf dem Bidschirm verhindert, 


4, Erste Erfahrungen 


Die Studenten sind bis auf wenige Ausnahmen motiviert durch 
die sie interessierende neue Technik und durch die Kenntnis 
einiger sie im späteren Studium erwartender Aufgaben- 
stellungen (z. B. in der Sektion Kraftfahrzeugtechnik die 
Anwendung des Systems PLOT (Grafik-System) zum automatisierten 
Konstruieren und Nutzung der Rechentechnik zur Wellenbe- 
rechnung oder in der Sektion Technologie die Arbeit an 
rechnergestützten Technologenarbeitsplatz und die Nutzung 

des sektionseigenen Prozeßrechners K 1630 in den höheren 
Semestern). Die gestellten Selbststudienaufgaben und eine 
häufig zu beobachtende geweckte schöpferische Neugierde 

haben eine hohe Auslastung des Rechentechnischen Kabinetts 

in der 2, und 3, Schicht zur Folge. Engpaß ist die begrenzte 
Verfügbarkeit der Rechentechnik, Wegen der z, T. ungenügen- 
den Vorbereitung der einzelnen Sitzungen durch die Studenten 
verschlechtert sich diese Situation noch etwas, Deshalb ist 
zu Beginn der selbständigen Nutzung eine Konsultationsmögs 
lichkeit effektiv und wird werktags bis 22,00 Uhr realisiert, 
Problematisch ist auch die Planung des 3. und 6. Seminar 

bei parallelen Seminargruppen, 
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Das Problem der UIC-Vergabe wurde gelöst durch Vergabe 
von Seminargruppen-UIC und Arbeits-UIC für jedes Terminal, 
Auf Grund der Vielzahl der Dateien mit relativ kleinem 
Umfang wurde die Praktikumsplatte mit großem Indexfile 
initialisiert {für 1200). 
Die Erfahrung zum "Anwendersystem” kann im Unterricht 
nicht vermittelt werden (da das System zu weit verzweigt ist), 
sondern sie wird im abendlichen individuellen Experimen- 
tieren gewonnen. Der durch ein Anwendersystem geführte 
Student baut schnell seine Anfangsscheu ab und ist relativ 
früh fähig, mit der Anlage zu arbeiten, blockiert jedoch 
während seiner "Lehrzeit" das Terminal. 
Ein mit Systemunterlagen Lernender benötigt eine längere 
Einarbeitszeit, ist aber in seinen Betriebssystemkenntnissen 
wendiger, 


5, Weitere Vorhaben 


Auf der Basis des vorgestellten Programmpaketes DIRAS, das 

in der ersten Ausbaustufe die Aufgaben des zentralen Steuer- 
‚moduls (DIALOG) ausführt, wird das Anwendersystem durch 
Lehrprogramme und Leistungskontrollen ergänzt. Der Anschluß 
einer Methodenbank (im RZ der TU Dresden in Arbeit) ist vor- 
gesehen, Lehrprogramme sollen insbesondere Probleme behan- 
deln, mit denen der Student bei selbständiger Nutzung ohne 
Konsultationsmöglichkeit konfrontiert werden kann, Die Ver- 
dichtung von zu speichernden Informationen soll den erforder- 
lichen Speicherbedarf von Textdateien, sequentiellen Ur- 
sprungsdaten der Lehrprogramme und der Direktzugriffsda- 
teien senken. Außerdem ist beabsichtigt, auf die sequen- 
tielle Ursprungsdatei gänzlich zu verzichten, indem ein 
spezielles Dientsprogramm ausgewählte Bilder der Direktzu- 
griffsdatei zur Korrektur mit EDI bereitstellt, 

Dem Anliegen des Schutzes bestimmter Informationen soll 
Rechnung getragen werden, indem vom Anwendersystemadministra- 
tor Teilgraphen und spezielle Knoten gesperrt werden können, 
Die Einbeziehung digitalgrafischer Komponenten ist beab- 
sichtigt. 
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Die Unterstützung der Arbeit des Lehrenden ale Autor 
von Lehrprogrammen oder Leistungskontrollen soll durch 
das Programmpaket AUTOR verstärkt werden. Eine Ausworte- 
komponente AUSWER soll ale Rückkopplung zwischen Lehrenden 
und Lernende dienen, 
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Abkürzungsverzeichnis 


BYE - MCR-Komnando zur Abmeldung 

CAI = Computer Aided Instruktion 

DIRAS - Dislograhnen CM4 | 

EDI - Editor 

FELI - Fehlerlistenaufbereitung 

FLI - Dienstprogramm zur bildschirmweisen Textausgabe 
(File-Listing. mit Interrupt) j 

FOR - FORTRAN IV-Compiler 

HEL - MCR-Kommando zur Anmeldung 

HIPO - Hierarchy Input Process Output 

MCR - Kommandoprogramn (Monitor-Consol-Routine) 

PAP - Programmablaufplan 

PIP - Dateitransferprogramnn (Peripheral Interchange 
Progran) 

RETTEN - Indirektkommandodatei zum Speichern (Retten) 


aus dem Arbeitsbereich in den Speicherbereich 
der Seminargruppe 


RGU - Rechnergestützter Unterricht 
RUN - Start einer Task 
STALRT] - Anwendereystem für lernende Nutzer 


TKB - Taskbuilder 
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Friedrich, Steffen 


Zu Kriterien für die Beurteilung von Lehrprogrammen 


Die gegenwärtige Entwicklung auf dem Gebiet der Mikroelektro- 
nik erfaßt wahrhaft alle Bereiche der Volkewirtschaft und 

des gesellschaftlichen Lebens. Es ist daher mehr als natür- 
lich, daß auch im Bereich der Bildung sich Bemühungen ver- 
stärken, um eine möglichst schnelle Nutzung neusster Entwick- 
lungen zu erreichen. Es liegen sicher eine Reihe positiver 
Effekte für die Ausbildung und die Erziehung unter Einbezie- 
hung dieser neuen Erkenntnisse auf der Hand. Die Integration 
von EDV und Mikroelektronik im Bildungswesen hat dennoch 
einen anderen Charakter als einfach die Übernahme einer neuen 
Technologie. Mit der Verwirklichung dieser Aufgabe werden 
erste Schritte zur Automatisierung geistiger Arbeit auch in 
diesen Bereich gegangen. Notwendigerweise ergeben sich dar- 
aus auch einige neue Fragestellungen, die gegenwärtig noch 
nicht klar beantwortet werden können, wie z. B. 


- In welcher Weise und wann sollten Computer in der 
Volksbildung genutzt werden? 


- Wio müssen wir uns langfristig darauf vorbereiten? 


- Wie ist gesichert, daß damit auch eine größere 
Effektivität erreicht wird? 


Bereite jetzt wird deutlich, daß zur Lösung der anstehenden 
Problene eino intensive interdisziplinäre Arbeit notwendig 
ist, die die Fachgebiete Informatik, Lernpsychologie,. Didak- 
tik, Fochmethodik, KI-Forschung u. a. umfaßt. 

Diese Arbeit wird insbesondere folgende Richtungen über- 
decken; | 


a) Lohren und Lernen mit Computern, d. h., der Computer ist 
Mittel im pädagogischen Prozeß. 


b) Lehren und Lernen von Computern, d. h., der Computer und 
eeine Funktionsweise sind Gegenstand des pädagogischen 
Prozesses. 


c) Testen und Prüfen nittels Computer, d. h., es liegt 
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ein spezieller Anwendungsfall vor. 


d) Verwalten mit Computern, d. h., es erfolgt eine Nutzung 
für spezielle Hilfsprozesse. 


Sicherlich müssen dabei Tendenzen, die diese Entwicklung 
fördern bzw. hemmen, berücksichtigt werden, um zu erreichen, 
daß das "Lernen auf Vorrat“ durch solche modernen Inhalte 
und Methoden abgelöst wird, die den Anforderungen an den 
Werktätigen der nächsten Jahrzehnte entsprechen. 


Diese allgemeinen Standpunkte umzusetzen heißt, konkret 
über Lösungswege eines sinnvollen Computereinsatzes im Bil- 
dungsbereich zu diskutieren. Dabei kann eine Konzentration 
auf folgende 3 Richtungen erfolgen: 


(1) COMPUTERVERSTANDNIS, 
im Sinne der Motivation und der Erzeugung positiver 
Haltungen zum Einsatz von Computern und damit 
gleichzeitig der Beseitigung "maschinenstürmeri- 
scher Zweifel” 


(2) COMPUTERBILDUNG, 
im Sinne der Beseitigung des Unvermögens zur Be- 
nutzung von informationsverarbeitenden Maschinen 
und der Herausbildung dafür notwendiger neuer 
Denkweisen. Bei der Entwicklung von Fähigkeiten 
und Fertigkeiten zur Benutzung von Computern ergibt 
sich eine Unterscheidung zwischen dem vorrangigen 
Einsatz als Mittel bzw. Gegenstand im pädagogischen 
Prozeß s 


(3) COMPUTERNUTZUNG , 
im Sinne der Anwendung für eine bereits ausgear- 
beitete Aufgabenstellung, um diese mit dem Mittel 
Computer schneller und besser zu lösen 


Diese aufgezeigten Richtungen dürfen allerdings nicht dazu 
führen, daß die Einsatzmöglichkeiten von vornherein be- 
schränkt und nicht in der ganzen Breite gesehen werden. 
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Eine Möglichkeit, Computer als Mittel im Prozeß der Bil- 
dung und Erziehung einzusetzen, sehen wir in Lehrsystemen 
auf der Basis von Mikrorechnern (vgl. /1/, /2/)« 
Ausgehend von Buchprogrammen hat es in den zurückliegenden 
Jahren vielfältige Entwicklungen vor allem auf Großrech- 
nern gegeben, die aber in verschiedener Weise auf Grenzen 
gestoßen sind. Das näher anzuführen, ist nicht unsere Ab- 
sicht. Es hat sich aber gezeigt, daß auf der Basis von 
Mikrorechnern neue Schritte möglich werden. Dabei werden 
neue Fragestellungen bedeutsam, . die die Nutzung von Compu- 
tern mit dieser Zielrichtung betreffen: 


a) Wie müssen Computer aussehen, die die Einsatzforderungen 
als Lehrsysten erfüllen können? 
(Das ist die Frage nach der Teachware des Systems, d. h. 
nach der technischen Gewährleistung und damit eine 
ingenieur-technische Aufgabe.) 


b) Wie müssen Programme gestaltet sein, damit der beab- 
sichtigte Effekt erreicht wird? 
(Das ist die Frage nach der Courseware des Systems, d. h. 
nach der inhaltlichen Gewährleistung und damit eine vor 
allem pädagogische Aufgabe.) 


Ohne auf den Teil der Entwicklung der Teachware genauer 
einzugehen, 501ll doch die Bedeutsamkeit an folgenden Ge- 
sichtspunkten verdeutlicht werden: 


- Lehrsysteme sollten auf der Basis von Mikrorechnern 
entstehen, die Großserien entstanmen 


- Sicherung einer einfachen Bedienung, vor allem durch 
ein Minimum an systemsichernden Tätigkeiten 


- durch vorhandene Systemfunktionen eine hohe Intelli- 
genz erzeugen 


- moderne Softwareentwicklungen zur weiteren Verbesse- 
rung nutzen 


Solche und ähnliche Gesichtspunkte wurden bei der Entwick- 
lung des Systems MLS/BC weitgehend beachtet (vgl. /3/, /4/). 
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Immer aktueller und bedeutsamer wird gegenwärtig die Frage 
nach der Entwicklung von Courseware, nach der Einordnung, 
Beurteilung und Nutzung entstandener Lehrprogramme. 

Mit dem Vorhandensein einer entsprechenden technischen 
Basis werden natürlicherweise Lehrprogramme entstehen, die 
nicht alle diesen Status verdienen. Damit wird eine stär- 
kere Differenzierung dringend erforderlich, denn es werden 
mit Lehrsystemen und zugehörigen Lehrprogrammen Erwartungen 
erzeugt und so auch Forderungen an das System gestellt. 


Eine differenzierte Beurteilung der Courseware kann Über- 
spitzungen abbauen und einen erfolgreichen Einsatz bewirken. 
Wir fassen Lehrprogramme als das Ergebnis der vom Pädagogen 
vorgeplanten Lehrhandlung auf, das durch adäquate Mittel 
dargestellt ist und den Rahmen für die Kommunikation des 
Benutzers mit dem Lehrsystem vorgibt. 

Funktionen, die Lehrprogramme unter didaktischer Sicht er- 
füllen können, stellen sich u. E. wie folgt dar: 


Funktionen 


Problem- 
bearbeitung 


Lehrunter- 
weisung 


; 4 % 
Simula Demon- 
tion stration 

j o 
Leistungs- tutorielle diagnosti- 
kontrolle Übung sche Übung 


Zur genaueren Charakterisierung sollen Antworten auf 3 Fra- 
gen dienen: 


(1) Wie ist der Aufbau des Gesamtprogramns? 
(2) Was geschieht durch Lernenden? 
(3) Wie ist die Lernersteuerung? 
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Mit der Übersicht wird ein Ansatz für Kriterien zur Ein- 
ordnung von Lehrprogrammen nach ihrer Funktion vorge- 
stellt. Durch zusätzliche Fragestellungen ist diese noch 
zu erweitern. Das erschwert allerdings eine praktikable 
Klassifizierung, die künftigen Lehrprogrammanwendern hel- 
fen soll. 

Wir vertreten die Auffassung, daß eine mitunter angestreb- 
te rein quantitative Charakterisierung von Lehrprogrammen 
zwar eine Einordnung lidfert, aber einen effektiven Zu- 
griff erschwert. Es erscheint sinnvoll, durch Nutzung von 
Dateiprojekten einen mehr qualitativen Zugriff auf Lehr- 
programme zu organisieren. Aus den Nutzungsraten sind 
direkt Konsequenzen für die weitere Programmentwicklung 
ableitbar. 

Das betrifft vor allem: 


- Lehrinhalte und mögliche Lehrstrategien 
Grundmodelle für LP-Typen 

- Systematisierung von Lehrinhalten 

Überlegungen zum Lerndialog, insbesondere einer 
brauchbaren Lernersteuerung 


Damit ergeben sich auch weitere Arbeitsrichtungen, die im 
Ergebnis dazu beitragen sollen, entstehende Lehrprogramme 
effektiv einzuschätzen, zu ordnen und den Zugriff darauf 
zu organisieren. 
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Ganmig, Frieder 


Erfahrungen bei der Implementierung und Nutzung des mikro- 


rechnergestützten Lehrsystems MLS/BC 3 


Seit mehr als zwei Jahren werden durch die Forschungsgruppe 
“Computer in pädagogischen Prozessen” der Pädagogischen Hoch- 
schule “Karl Friedrich Wilhelm Wander" Dresden u. a. Probleme 
der Computeranwendung zur individuellen Steuerung eines 
pädagogischen Prozesses bearbeitet. Dabei stand die Aufgabe, 
basierend auf entsprechenden Voruntersuchungen, nicht nur Lö- 
sungen des computergestützten Unterrichts der 70er Jahre 
erneut zu einem System zusammenzuführen, sondern ein System 
zu entwickeln, das für die Einbindung neuer Mittel und Metho- 
den weitgehend offen ist. B i 
Besonderer Wert wurde auf die Planung und Realisierung -der 
Schnittstelle Mensch-Maschine gelegt. Diese Schnittstelle be- 
steht in dreierlei Hinsicht (Lehrprogrammautor-Maschine, 
Lernender-Maschine, Bediener-Maschine). 

Darüber hinaus wurden bei der Konzeption von MLS pädagogisch 
und didaktisch begründete Modelle und Standpunkte zu Fragen 
der lernverlaufsabhängigen Lenkung der Antwortkontrolle und 
der pädagogischen Diagnose einbezogen. 

Die Konzeption wurde weiterhin beeinflußt durch moderne Ver- 
fahren und Methoden der künstlichen Intelligenz, die in Lehr- 
systemen effektvoll einsetzbar sind (Formelmanipulation, 
Computersimulation, Computerdiagnostik). 

Schließlich beeinflußten eine Reihe prognatischer Aspekte 
bzu. Erfahrungen anderer Lehrsystemlösungen die Art und Weise 
der Realisierung von MLS.. } 


1. Die Anwendungsbreite und Anwendungshäufigkeit hängt wesent- 
lich von der Verfügbarkeit der Basismaschinen für Lehr- 
systeme ab. 

Deshalb wurde MLS in der Variante MLS/BC für Bürocomputer 
implementiert, die serienmäßig hergestellt werden. 


2. Der Anwendungseffekt und die Nachnutzbarkeit des Systems 
hängt ab von Qualität und Aktualität der das System stützen- 
den Betriebssoftware, von der Qualität der Lehrprogramme 
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und von der Qualität der speziell für das Lehrsystem 
existierenden Einfahrhilfen. 


Die wohl wichtigste Fragestellung für Lehrsysteme ist die, 

wie der das Lehrsystem einsetzende Lehrer die entsprechenden 

Programme schreiben kann. Zur Unterstützung dieses Prozesses 

wurde eine spezielle Lehrprogrammformulierungssprache (LEFO) 

entwickelt. 

Lehrprogramme für Computer, selbst eingebettet und einge- 

setzt in einen globalen didaktischen Prozeß, zielen auf einen 

durch Einsatzgebiet, Lehrziele und Lehrmethoden charakteri- 

sierbaren lokalen Lehr- und Lernprozeß. 

Dafür müssen sowohl Bedingungen seitens des gewährleistenden 

Systems als auch seitens des Lehrprogramms erfüllt sein. 

Dieser speziellen Zielsetzung Rechnung tragend, wurde die 

Sprache "LEFO" entwickelt, die auf einem pädagogisch begründ- 

baren Lenkungsmodell einer höheren Anforderungen genügenden 

Antwortkontrolle und einem speziellen Datenkonzept basiert. 

Charakteristisch für LEFO ist: 

- die strenge Trenriung zwischen dem Zeitpunkt und dem Ort 
der Eingabe und der Verwendung der Lehrprogrammtexte, 

- der'parametrisierte Sprachaufbau, 

.- die gute Lesbarkeit der LEFO-Befehle, 

- das fachsprachenähnliche Übersetzungsprinzip mittels Vor- 

übersetzern, das eine weitgehende Portabilität von LEFO 

gestattet, 

die Umsetzung der LEFO-Befehle durch Semantikbausteine 

(Prozeduren), die in höheren Programmiersprachen (z. B. 

PASCAL) geschrieben werden. 


Die LEFO-Grundbefehle stellen komplexe Bausteine für nahezu 
alle dankbaren pädagogisch-methodischen Handlungen dar. 
LEFO ist eine pädagogisch-methodische Fachsprache. 


Für MLS wurden eine Reihe von Modellen entwickelt, die durch 
ihre Umsetzung in MLS/BC bereits eine gewisse Fundierung er- 
fahren haben. Diese Modelle sind offen und für andere Lösun- 
gen übertragbar. Sie bilden die Grundlage, wenn im mündlichen 


Vortrag mehr über ein portables mikrorechnergestütztes Lehr- 
8aysten gesagt werden soll. 
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Mit MLS/BC wird für das Volkebildungsnesen der DDR eine Vor- 
laufentwicklung betrieben. 
Es ist nicht zu erwarten, daß Bürocomputer für diesen Zweck 
in größeren Stückzahlen in den Oberschulen der DDR zum Ein- 
satz kommen werden. Für die dagegen verfügbaren Heimcomputer 
ist das hier vorgestellte MLS noch nicht einsetzbar. Diesen 
Homecomputern fehlen noch Diskettenlaufwerke und Drucker als 
Hardwareergänzung sowie ein leistungsstärkeres Betriebssystem 
mit einem PASCAL-Compiler als Softnareergänzung. Es darf aber 
angenommen werden, daß diese Ergänzungen entsprechend zum 
internationalen Trend verfügbar sein werden. Dann hat man auch 
bald eine MLS/HC (Heimcomputer)-Variantel 
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Rechnergestütztes Planspiel KOMBINAT in der Aus- und 
Weiterbildung von Führungskadern 


1. Rechnergestützte Planspiele zur Nachahmung der Ver- 
haltensweise realer ökonomischer Prozesse 


Rechnergestützte Planspiele sind als eine interdiszipli- 
näre Form der Untersuchung und Darstellung komplexer öko- 
nomischer Vorgänge anzusehen. Der handelnde ilensch steht 
bei.ihnen im Wittelpunkt des Interesses. Die Teilnehmer 
können in die Rolle des Lehrenden, des Lermenden oder des 
Forschenden schlüpfen und im Spiel bei hinreichender 
Komplexität des Gegenstandsbereiches ganz unterschiedliche 
Formen der Zusammenarbeit entwickeln. So lassen sich Ent- 
scheidungssituationen unter mehr oder weniger großer 
Ungewißheit simulieren, die Teilnehmer können Bedingungen 
des sozialistischen Wettbewerbs vorfinden oder sich im 
Rollenspiel innerhalb von Leitungshierarchien bewegen. 


In einem Planspiel stellen die Spielteilnehmer mit ihren 
Entscheidungen einen aktiven Bestandteil dar, den sog. 
Aktionsbereich, 

Der Gegenstand der ökonomischen Analyse im Spiel, d.h. die 
konkrete Situation, auf die die zu treffenden Entscheidun- 
gen angewandt werden, wird durch das Simulationsmodell si- 
muliert. Auf Grund der Entscheidungen wird das Modell von 
einer Ausgangssituation in einen neuen Zustand überführt. 
Das Simulationsmodell wird daher im Planspiel als Reaktions 
bereich bezeichnet. 


Die Dynamik realer Prozesse wird im Planspiel nunwehr durch 
eine Aufeinanderfolge von Entscheidungsperioden, also eine 
zeitliche Sequenz von Wechselwirkungen zwischen Aktions- 
und Reaktionsbereich nachgeahnt. 


Die Entwicklung komplexer Planspiele steht in engem dialek- 
tischem Zusammenhang zur Entwicklung der ökonomischen Theorie. 
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Zur Simulation ökonomischer Prozesse in einem Planspiel sind 
erforderlich: 


1. Die qualitative Beschreibung der ökonomischen Er- 


scheinungen. So hängt z.B. die Entwicklung der Arbeits” 


produktivität in einem Betrieb u.a. ab vom Einsatz 
von Wissenschaft und Technik, der Qualifikation der 
Arbeitskräfte, der Organisation des Produktionspro- 
zesses USW... 

2. Die Quantitative Bestimmung dieser ökonomischen Ge- 

setzmäßlgkeiten. 
Es muß also z.B. ermittelt werden, wieviel % Stei- 
gerung der Arbeitsproduktivität durch welchen Auf- 
wand an finanziellen oder materiellen Mitteln er” 
reicht wird. 

3. Die durchgängige Darstellung aller für den realen 
Prozeß und die Einsatzziele des Spieles relevanten 
Zusammenhänge in Form von Algortkhmen, die nach ent- 
sprechender Programmierung auf einer Rechenanlage 
abgearbeitet werden müssen. 


Hieraus ergibt sich die Forderung nach einem hohen Entwick- 
lungsniveau der vom Gegenstandsbereich des Spiels berührten 
Wissenschaftsdisziplinen (Betriebswirtschaft, Volkswirt- 
schaft, Finanzen usw.) und zugleich d. ne enge Verbindung 

mit Wethoden und Verfahren der Analyse ökonomischer Prozesse 
(Mathematik, Statistik). 

Für die technische Realisierung komplexer Spiele wurden bis- 
her überwiegend Rechenanlagen im off-line Betrieb mit Daten- 
erfassung über Lochkarte oder Lochband sowie Ausgabe der Er“ 
gebnisse über Druckliste eingesetzt. 


Die Verfügbarkeit von Bildschirmtechnik bei Fernverarbeitung 
mit Großrechnern oder im Anschluß an leistungsfähige Klein- 
rechentechnik schafft gegenwärtig neue Wöglichkeiten der 
Nutzung von Planspielen. Das bedingt aber zugleich auch die 
Entwicklung neuer Konzeptionen zur Gestaltung von effektiven 
Einsatzformen solcher Spiele für die Aus- und Weiterbildung 
von Wirtschaftskadern. 


£4 
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2. Mehrebenenplanspiel  KONBINAT 


2e1e Übersicht Über die Struktur des Spiels 

Im Planspiel KOMBINAT nehmen die Teilnehmer Verantwortlich- 
keiten in mehreren hierarchisch zueinander stehenden Leitung“ 
ebenen wahr. 


Spielleitung 


KOMBINAT A KOMBINAT B 


Betrieb 1 Betrieb 2 Betrieb 1 | |Betrieb 2 


Simulationsmodell 
BES 4 


Die Anzahl der Kombinate im Spiel sowie die Zahl der Betriebe 
in jedem Kombinat ist frei wählbar. Vor Spielbeginn sind jedoch 
von der Spielleitung entsprechende Datenbasen zu generieren. 


Die Betriebe können bei Spielbeginn von der gleichen Ausgangs“ 
situation ausgehen. Es ist jedoch auch möglich und aus 

Gründen der Ausarbeitung differenzierter Kombinatsstrategien 
zu empfehlen, m Iche Ausgangssituationen zu generieren, 

bei denen sich die Betriebe innerhalb der Kombinate unter- 
scheiden. 

Das Planspiel kann bis zu 6 Perioden umfassen, wobel in jeder 
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Periode ein Zeitraum von 6 Monaten simuliert wird. 
Es 1st jedoch auch möglich, Perioden zu wiederholen oder 
von einer bestimmten Situation als Ergebnis eines Simula- 
tionslaufes aus mehrere Entscheidungsvarianten für eine 
Periode durchzurechnen. 


Die Spielleitung repräsentiert die zentralen staatlichen 
Planungs und Leitungsorgane. Sie ist als das zuständige In* 
dustrieministertum anzusehen, vertritt aber zugleich auch 
endere Verantwortungsbereiche, wie z.B. Organe, die für 

die Bilanzierung und Realisierung von Außenhandelsgeschäf- 
ten verantwortlich sind. j 

Von der Spielleitung erhalten die Kombinate alle Planzahlen 
und weitere Informationen. Ihr gegenüber rechnen die Kombi- 
nate ihre Pläne ab und legen Rechenschaft über die Effek- 
tivität der Arbeit in den den Kombinaten nachgeordneten 
Betrieben. 


Auf der Leitungsebene der Kombinate übernehmen Spielteil- 
nehmer die Verantwortlichkeit der Leitung von Industrie- 
kombinaten, denen mehrere Betriebe unterstellt sind. Eine 
spezielle Aufgabe entsteht den Kombinaten in der Wahrneh- 
mung der Funktionen eines ihnen zugeordneten Außenhandels- 
betriebes (AHB). 


Die niedrigste Leitungsebene des Spiels ist mit der Lei- 
tung der Kombinatsbetriebe beauftragt. Die hierbei getrof- 
fenen Entscheidungen sind Eingangsdaten für Simulations- 
läufe, bei denen das Simulationsmodell BES 4 (GERNERT/ 
MESSERSCHMIDT, HUB, 1984) das Verhalten der betreffenden 
Betriebe simuliert. Dieses liodell ist eine Weiterentwick- 
lung des lodells BES 1 (GERNERT/KÖLZOW, HUB, 1974). 


Das Planspiel KOMBINAT ist modular aufgebaut. Es kann in 
der hier beschriebenen Form durchgeführt werden. Es ist 
jedoch auch möglich, mit Hilfe des Wodells BES 4 nur die 
betriebliche Leitungsebene zu simulieren. Aus dieser An- 
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wendungsvariante ergeben sich dann Planspielformen, die dem 
Planspiel BES 1 formal entsprechen, 


Gleichzeitig kann das Modell KOMBINAT unter Angliederung 
von zwei Teilmodellen, die ausgewählte Bereiche der Wirt- 
schaft Großbritanniens beschreiben, zu dä nem internationa- 
len Handelsspiel DDR-Großbritannien ausgebaut werden. 


2.2. Leitungsebene KOMBINAT 


In ihrer Funktion als wirtschaftsleitendes Organ übergibt 
die Spielleitung der Kombinatsleitung folgende Unterlagen: 


- Bedarfszahlen für abzusetzende Erzeugnisse in der 
Folgeperiode, untergliedert nach Produkten und Absatz 
gebieten. Die Exporte in das NSW sind dabei Ergebnis 
der Verhandlungen des AHB (Menge, Termine, Preise). 


- Planzahlen für jeweils ein Flanjahr, aufgegliedert 
nach Perioden. 


- volkswirtschaftiich bilanzierte Ressourcen auf dem 
Gebiet der Investitionstätigkeit. 


= Angaben zur Finanzierung von Investitionen und von 
Waßnahmen auf dem Gebiet von Wissenschaft und Technik. 


- Weltere Informationen, die sich aus aktuellen volks- 
wirtschaftlichen Entwicklungen ergeben. 


Für die die Kombinatsleitung repräsentierenden Spielteilneh- 
mer ergeben sich zwei Aufgabenbereiche: 


1. Entscheidungen zur Planung und Leitung der dem 
Kombinat nachgeordneten Betriebe, 
Jeder dieser Betriebe ist im Rahmen des kombinats- 
verbandes selbständig. Die Planauflagen des Indu- 
‘ strieministeriums (Spielleitung) sind daher auf die- 
se Betriebe aufzuschlüsseln. Dabei ist die jewei- 
lige wirtschaftliche und technologische Situation 
dieser Betriebe zu beachten. 
Das Kombinat bildet und verwendet zentralisierte 
Fonds, um seine mit der volkswirtschaftlichen Auf- 
i zabenstellung übereinstimmende ‚irtschaftsstrate- 
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gie langfristig durchsetzen zu können. 

Der Investfonds wird aus Amortisationsanteilen der 

Betriebe gebildet. Diese Mittel können in Überein- 

stimmung mit der Investitionsstrategie des Konbi- 
‚nates an die nachgeordneten Betriebe umverteilt 

werden, 

Gleiches gilt für den Fonds Wissenschaft und 'Tech- _ 

nik. 

Die Spielleitung kann in ihrer Rolle als Ministe- 

rium beiden Fonds weitere Nittel zu führen bzw. 

Wittel abziehen, 


2. Realisierung der Arbeit des Außenhandelsbetriebes. 
Der zweite Entscheidungsbereich der Kombinatslei- 
tung umfaßt alle Import- und Exportaktivitäten des 
gesamten Kombinates. f 
Dazu hat der AHB folgende Aufgaben durchzuführen; 

- Ermittlung des voraussichtlichen Bedarfes 
für die produzierten Erzeugnisse im RGi- 
Bereich und in Großbritannien. 

‘= Abschluß von Lieferverträsen nach Nenge, 
Preis, Qualität und Zielland je Erzeugnis 
für Jede Simulationsperiode. 

- Verhandlung der Importbedingungen für Robo- 
ter nach Nenge, Preis (VCW) und Importabgabe- 
‚preis bei Einhaltung des bestätigten Import- 
volumens insgesant. 

- Ermittlung der Ergmisse der Exporttätig- 
keit des AHB für jede-Perlode. 

Der AHB des Kombinates arbeitet nach dem Prinzip 
der Wirtschaftlichen Rechnungsführung. Für jede 
Simulationsperiode sind daher ausgewählte Kosten 
und Erlöse aus der außenwirtschaftlichen Tätigkeit 
des AHB zu berechnen und zusammenzustellen. 


Die Kombinatsleitung ist nach jeder Periode gegenüber dem 
Ministerium rechenschaftspflichtig und nimmt die Rechenschafts- 
legung der nachgeordneten Betriebe entgegen. 
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2.3. Leitungsebene Betrieb 


Für jeden Kombinatsbetrieb sind in Jeder Periode Entschei” 
dungen auf den Gebieten Produktion, Wissenschaft und Tech- 
nik, Ausrüstungen, Arbeitskräfte, üaterlal sowie Bildung 

und Verwendung betrieblicher Fonds zu treffen. Diese Ent- 
scheidungen sind aus der Ausgangssituation bzw. der Vorperi- 
ode und aus den Planauflagen der kombinatsleitung abzuleiten. 


Die folgenden Ausführungen enthalten einige Informationen 
über den mit dem Modell BES 4 simulierten betrieblichen 
Prozeß. Sie sind den Komplexen Produktionssortiment, Aus“ 
rüstungen, Arbeitskräfte, Naterial und Fondsbildung zu” 
geordnet. 


Produktionssortiment: 

Zu Beginn des Planspiels produziert jeder Kombinatsbetrieb 
zwei Erzeugnisarten, die sich als PKW (E1) und komplette 
Sätze von Ersatzteilen dazu (E2) interpretieren lassen. 
Während des Spiels wird ein neues PKW-Wodell (E3) mit den 
dazugehörigen Ersatzteilen (E4) in die Produktion einge- 
führt. 

Das Kombinat verkauft seine Erzeugnisse auf drei Absatzge- 
bieten (DDR, RGW, Großbritannien). 

Jedes Erzeugnis kann in drei Güteklassen produziert werden. 
Die Aufgabe der Entscheidungstätigkeit besteht in der Ge- 
währleistung einer bedarfsgerechten Produktion bei Ein- 
haltung. aller Plankennziffemn. 


Ausrüstungen: 
‘Um die Planauflagen der Kombinatsleitung zur Steigerung der 


Effektivität der Produktion, zur Erreichung des Exporter” 
gebnisses und einer bedarfsgerechten Produktion realisieren 
zu können, ist das technologische Niveau der Produktion 
wesentlich zu erhöhen. 

Durch gezielte Investitionsmaßnahmen ist es möglich, eine 
bestimmte Anzahl von produzierenden Einheiten durch rekon- 
struierte Naschinen der DDR-Produktion und durch Roboter 
aus NSW-Importen zu ersetzen. 
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Die Struktur und der Umfang der vorzunehmenden Investitionen 
ist durch die Planaufgaben zu begründen und hängt von der 
Zustimmung der für die Bilanzierung des Betriebes zustän- 
digen Kombinatsleitung ab. 


Arbeitskräfte: 

Für eine Erarbeitung der Kapazitätsbilanz ist eine Gegenüber 
stellung des Arbeitsvermögens der Arbeitskräfte und der In- 
anspruchnahme dieses Zeitfonds durch das geplante Produk- 
tionsvolumen erforderlich, 

Die zur Herstellung einer Einheit eines Erzeugnisses er- 
forderlichen Arbeitsstunden sind zu Spielbeginn der Aus- 
gangssituation zu entnehmen. Diese Angaben verändern sich 
während des Spielverlaufes unter Einwirkung der jeweils 
realisierten “aßnahmen im Bereich Wissenschaft und Technik. 
Hierbei werden wirksam: Forschungsmittel, Ausgaben für WAO, 
Qualifizierung der Arbeitskräfte, Verschleißquote, Einsatz 
rekonstruierter Ausrüstungen und insbesondere von Robotern, 
Ausschußquote. 


Durch gezielte Freisetzung von Arbeitskräften, Neueinstellun- 
gen und liaßnahmen zur Verbesserung der Arbeits- und Lebens- 
bedingungen kann das Arbeitsvermögen des Betriebes mit den 
Planaufgaben in Übereinstimmung gebracht werden. 


Material; : 

Die zur Herstellung einer Einheit eines Erzeugnisses erfor” 
derlichen Nengeneinhelten sind der Ausgangssituation zu ent 
nehmen, 

Während des Spiels läßt sich dieser Aufwand durch laßnahmen 
der Intensivierung des Produktionsprozesses verändern. 
Hierbei werden wirksam: Forschungsmittel, Verschleißquote, 
Einsatz von rekonstruierten Ausrüstungen und Robotern, Aus“ 
schußquote. 


Die Entscheidungen für Materialbestellungen sind mit den 
Produktionsaufgaben der entsprechenden Perioden abzustim-” 
men, damit der Betrieb mit ökonomisch vertretbaren laterial- 
'beständen arbeiten kann. 
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Fondsbildung: 
Zur umfassenden Intensivierung des Reproduktiönsprozesses 
sozialistischer Industriebetriebe sind Bildung und Verwen- 
dung des Fonds Wissenschaft und Technik sowie des Investi- 
tionsfonds von besonderer Wichtigkeit. 


Beide Fonds werden in den durch BES 4 simulierten Betrieben 
gebildet. Die Kombinatsleitung hat die Möglichkeit, üittel 
aus diesen Fonds zwischen den ihr unterstellten Betrieben 
so umzuverteilen, daß ein effektiver Einsatz aller Ressour“ 
cen möglich wird. 


oe Einsatzmöglichkeiten und -bedin en 


Komplexe Nehrebenenplarspiele bieten eine gute Möglichkeit 
zur Intensivierung der Aus“ und Weiterbildung von Wirt- 
schaftskadern, weil man mit ihrer Hilfe im Rahmen des Aus- 
bildungsprozesses und ohne Übernahme des Risikos materieller 
Verluste ausgewählte Leitungsaufgaben demonstrieren und 

ihre Lösung üben kann. 


Zur Durchführung des Planspiels KOMBINAT werden mehrere Teil- 
nehmergruppen gebildet, für deren Zusammensetzung folgende 
Empfehlungen gelten: 
- jedes Betriebsleitungskollektiv 3 - 4 Teilnehmer, 
- Kombinatsleitung ca. 4 Teilnehmer, 
- In Abhängigkeit von der Zahl in einem Spiel geführter 
Kombinate und Betriebe sollte sich die Spielleitung 
aus 2 = 3 Personen zusammensetzen. 


Äls Mehrebenenplanspiel orientiert sich KOMBINAT stark 

auf die Diskussion und die Verhandlungsführung zwischen den 
Teilnehmern, die sich aus umfassenden Analysen der jeweiligen 
Simulationsergebnissen ableiten. i 

Damit ergibt sich eine sehr aktive und infolge ihrer Dynamik 
und Komplexität auch praxisnahe Lehrform. Es werden keine 
Einzelkenntnisse 'abgefragt', sondern die Teilnehmer müssen 
es lernen, ökonomische Prozesse in ihren VIechselwirkungen 

zu analysieren und planmäßig zu leiten. 
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Das von K. Messerschmidt (ORZ der HUB) für das hiodell BES 4 
erarbeitete umfangreiche Programmpaket enthält ca. 4500 
FORTRAN-Anweisungen. Die für die Abarbeitung des Programms 
erforderliche Hauptspeicherkapazität beträgt ca. 76 KByte. 


Für die Eingabe der Entscheidungen bzw. die Ausgabe der 
Ergebnisse werden Bildschirmgeräte des AP 64 unter Nutzung 
des TSO eingesetzt, die an ESER-Rechner EC 1022 bzw. EC 
1055 angeschlossen sind. 


Das Planspiel KOMBINAT wurde während des 10. Internationalen 
Seminars über rechnergestützte Planspiele vorgestellt, das 
von der Sektion Wirtschaftswissenschaften der Humboldt- 
Universität zu Berlin im Dezember 1984 durchgeführt wurde. 
Es steht zur Nachnutzung zur Verfügung. 


Verfasser: 

Doz. Dr. sc. oec. Hans Gernert 

HRumboldt-Universität zu Berlin 

Sektion Wirtschaftswissenschaften + 
Bereich Statistik 


1020 Berlin 
Spandauer Str. 1 


Hartwig, W.=H. 


Grundpositionen und erste Erfahrungen zum Einsatz des Lehrsystems AOS VUZ im Lehr- 
und Studienprozeß an der TU Dresden 


Die zunehmende Verbreitung moderner Informationstechnologien zur Automatisierung gei= 
stiger Prozesse als einer Schlüsselposition des wissenschaftlich-technischen Fortschritts in 
der gesamten Volkswirtschaft führt zu bedeutsamen Konsequenzen für Inhalt und Gestaltung 
von Ausbildungsprozessen an den Hoch- und Fachschulen unseres Landes. So wird es vor 
allem erforderlich, praktisch alle Studenten im Verlaufe ihres Studiums zur Beherrschung 
derjenigen rechnergestUtzten Arbeitsweisen zu führen, die für die Tätigkeit in ihrer sp&te- 
ren beruflichen Praxis charakteristisch sind bzw. zukünftig sein werden. Zum anderen gilt 
es, die Möglichkeiten der modernen Rechentechnik zielstrebig zu nutzen, um ausgewählte 
Lehr- und Aneignungstätigkeiten von Hochschullehrern und Studenten zu intensivieren und 
so die Effektivität der Ausbildung im ganzen erhöhen zu helfen. Diesem Einsatzfeld von 
EDVA, das mit Stichworten wie "rechnergestUtzte Lehrsysteme und -programme" und/oder 
"computerunterstUtzter Unterricht" umrissen werden kann, wendet sich der vorliegende 
Beitrag zu. Er soll dazu dienen, ein hochschulpädagogisches Untersuchungsprojekt vorzu- 
stellen, das vom Forschungszentrum fUr technische Lehr- und Lernmittel der TU Dresden in 


Zusammenarbeit mit einigen Lehrkollektiven dieser Universitüt in Angriff genommen wurde. 


In den letzten Jahren wurden im Rahmen eines "Komplexprogramms von Arbeiten zur 
Schaffung rechnergestützter Lehrsysteme auf der Basis von EDVA" des MHF der UdSSR so- 
wie entsprechender Festlegungen im Zielprogramm des Staatlichen Komitees für Wissen- 
schaft und Technik in zahlreichen sowjetischen Hochschulen und Weiterbildungszentren 
rechnergestUtzte Lehrsysteme implementiert und zumindest experimentell in den Ausbil= 
dungsprozeß eingeführt, Der größte Teil von ihnen basiert auf einer unter Leitung des 
Moskauer Forschungsinstituts für Probleme des Hochschulwesens (NIIVS) entwickelten 
Familie von Anwenderprogrammpaketen, deren gegenwärtig aktuellste Generation die 
Bezeichnung AOS VUZ (Abkürzung für die russische Entsprechung von "rechnergestUtztes 
Lehrsystem für Hochschulen") trägt. Sie wurde vom "Wissenschaftlichen Rat für Probleme 
der Schaffung und Anwendung rechnergestützter Lehrsysteme" beim MHF der UdSSR als 
Typenprojekt bestätigt und zur breiten Nutzung in der Ausbildungspraxis empfohlen. 
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Als Voraussetzung dafür wurde u. a. eine umfassende Dokumentation herausgegeben, die 
Systemunterlagenwartung zentral organisiert und mit der periodischen Herausgabe eines 
Lehrprogrammkatalogs für AOS VUZ begonnen. Weiterhin sind Anstrengungen zur Qualifi= 
zierung von Hochschullehrern als Lehrprogrammautoren eingeleitet und methodische Arbei- 
ten zur Lehrprogrammgestaltung geführt worden. Derzeit ist AOS VUZ an über 100 Bil- 
dungseinrichtungen der UdSSR eingeführt, die Zahl der Bestellungen ist noch weitaus höher. 


Das Lehrsystem AOS VUZ sichert die Realisierung von Lehrprogrammen im Dialog zwischen 
Lernendem und System Uber standardmüßige Bildschirmdisplays verschiedener Typen und 
unterstützt die Arbeit von Lehrprogrammautoren, aufsichtsführenden Hochschullehrern und 
Angehtrigen des technischen Betreuungspersonals. Für jeden Nutzertyp existieren spezielle 
Kommunikationsmittel (Kommandosprachen), die auf die von ihm zu Iösenden Aufgaben zu= 
geschnitten sind. Lehrprogramme werden mit Hilfe der Autorensprache JAOK auf Quell=- 
textniveau formuliert, eingegeben und getestet. Es handelt sich dabei um eine spezielle 
Programmiersprache mittleren Niveaus, die sowohl assemblerhafte Zuge als auch Merkmale 
einer problemorientierten Sprache trügt. Durch Möglichkeiten der Verwendung von Makros 
und Unterprogrammen sowie zusätzlicher, in Maschinensprache geschriebener Funktionen 
unterstützt sie’die Modularität der Programmierung und sichert die Offenheit des Systems 
gegenüber beliebigen Weiterentwicklungen. AOS VUZ ist in mehreren Versionen für unter- 
schiedliche gerütetechnische Konfigurationen verfügbar, die in der Pornakiive das gesamte 
Spektrum moderner rechentechnischer Mittel umfassen werden, darunter auch Klein- und 
Mikrorechner. Ausführlichere Informationen zum Lehrsystem AOS VUZ können u. a. /1/ 


und /2/ entnommen werden. 


Im Hochschulwesen der DDR wurden ab Anfang der siebziger Jahre unter koordinierender 
Beratung des Forschungszentrums für technische Lehr- und Lernmittel der TU Dresden einige 
Entwicklungsarbeiten auf dem Gebiet rechnergestützter Lehrsysteme betrieben. In ihrem 
Ergebnis entstanden solche Projekte wie LEDA, MERUS, REGEL und RGU (vgl. z. B. /3/). 
Ihre pädagogische Erprobung, so begrenzt sie z. T. auch wegen der beschrünkten geräte- 
technischen Basis bleiben mußte, bewies zumindest zweierlei: Einmal die potentielle 
Möglichkeit, mit Hilfe solcher Systeme Intensivierungseffekte im Ausbildungsprozeß zu 
erreichen, zum anderen aber auch die Notwendigkeit, dafür eine Reihe spezifischer Vor- 


aussetzungen zu schaffen. Eine davon besteht darin, daß sich der hohe für die Entwicklung 
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niveauvoller Lehrprogramme benttigte Aufwand nur dann in spUrbare pödagogische Effekte 
umsetzen kann, wenn die breite Nutzung der Ergebnisse gewährleistet ist. Daraus resultie- 
ren Forderungen nach Verwendung standardmüßiger Gerttetechnik und Betriebssoftware so- 
wie nach zentralisierter Lehrprogrammentwicklung, die von den oben genannten Lehrsyste- 


men nicht erfullt werden konnten. 


In Auswertung der gesammelten Erfahrungen und unter Berücksichtigung des internationalen 
Standes wurde zu Beginn der laufenden Funfjahrplanperiode im Forschungszentrum fur tech- 
nische Lehr- und Lernmittel die Entscheidung getroffen, in enger Forschungskooperation 
mit dem Moskauer NIIVS weitere Untersuchungen zur Entwicklung und zum Einsatz rechner- 
gestUtzter Lehrsysteme durchzuführen. In Anbetracht des ausgereiften Entwicklungsstandes 
der Lehrsystemfamilie SPOK-VUZ (Vorgänger von AOS VUZ fur DOS/ES, vgl. /4/) und 
der Notwendigkeit, bei der Fülle der zu Iösenden Aufgaben die in den sozialistischen Lün- 
dern verfügbaren Kräfte in optimaler Arbeitsteilung einzusetzen, wurde auf weitere Eigen- 
entwicklungen verzichtet und statt dessen die Übernahme von AOS VUZ an die TU Dresden 
vorbereitet. Als echtes Produkt internationaler sozialistischer Forschungskooperation wurde 
auf der Grundlage einer in der TU Dresden erarbeiteten "Püdagogisch-technischen Aufga- 
benstellung zur Einführung des Lehrsystems AOS VUZ in den Experimentalbetrieb an der 

TU Dresden" vom Moskauer NIVS in Zusammenarbeit mit dem MIIGA (Moskauer Institut 
für Zivilluftfahnt) die Systemversion AOS VUZ/AP-64 entwickelt, die für den Einsatz an 
der TU Dresden geeignet ist. Ihre Übergabe durch den sowjetischen Partner erfolgte im De- 
zember 1984 am Rechenzentrum der TU Dresden. 


Als gerätetechnische Basis dient eine EDVA ES-1022, die Über 512 KByte Hauptspeicher- 
kapazitüt verfügt. Über einen Multiplexor MPD 4 vom Typ ES 8404 ist ein Abonnenten- 
punkt AP-64 mit 5 Bildschirmen und einem Mosaikdrucker angeschlossen, der die Kommu- 
nikation der Nutzer mit dem System sichert. An weiteren Ressourcen sind eine Magnet- 
platteneinheit vom Typ ES-5061 sowie ein bis zwei Magnetbandgeräte erforderlich. 
Paralleldrucker und Lochkartenleser werden nur zeitweise benttigt. Als Betriebssystem 


wird die OS/ES-Version 6.1 M4B genutzt. 


Dem experimentellen Einsatz der Lehrsystemversion AOS VUZ/AP-64 an der TU Dresden 


werden eine Reihe von Positionen zugrundegelegt, die sich aus den bisherigen Erfahrungen 
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des Einsatzes rechnergestützter Lehrsysteme sowie speziell entwickelter Lehrgeräte erge- 


ben und sich z. T. bereits in der Ausbildungspraxis bewährt haben, Einige der wichtigsten 


sollen bier stichpunktartig angegeben werden. 


= RechnergestUtzte Lehrsysteme sind ihrer Natur nach technische Gebilde (Einheit von 
Programm= und Gerütetechnik), ihre Zwecksetzung ist jedoch didaktisch und wird vom 
jeweiligen Lehrprogramm bestimmt. Püdagogisch begründete Anforderungen an die Ge- 
staltung derartiger Systeme mUssen demzufolge von den Forderungen ausgehen, die an 
durch sie zu realisierende Lehrprogramme zu stellen sind. Dabei werden nicht nur einzel- 
ne, sondern bestimmte Klassen von Lehrprogrammen zu berücksichtigen sein. 

= Zu den vorrangigen didaktischen Einsatzorten rechnergestützter Lehrsysteme zuhlen vor 
allem solche Prozesse im Selbststudium sowie in den Lehrveranstaltungsformen Übung, 
Seminar und Praktikum, die auf das Festigen von Kenntnissen, das Ausprägen spezieller 
Fühigkeiten und die Entwicklung geistiger und manueller Fertigkeiten gerichtet sind und 
dabei besonders der differenzierten Führung der Lernenden bedürfen. In diesem noch rela- 
tiv weit gefaßten Bereich ist der Lehrsystemeinsatz gegenüber der. Verwendung anderer 


Hilfsmittel vor allem.dann als dringlich anzusehen, wenn 


. die Lehrprogrammrealisation mit umfangreichen und/oder komplizierten Aufgaben der 
Informat ionsverarbeitung verbunden ist (Generierung von Aufgaben und Texten, Ana= 
lyse relativ frei formulierter Antworten, Diagnose- und Protokollführungsaufgaben 
u. a.) und/oder 

. der Rechner gleichzeitig als Gegenstand oder Arbeitsmittel, in die zu lenkende Lern- 
tätigkeit einzubeziehen ist und/oder 

. ein geeignetes EDV-Gerütesystem bereits vorhanden ist und störker für Ausbildungs- 


aufgaben genutzt werden kann.’ ' 


= Die Lehrprogrammentwicklung sollte von der Auftragserteilung an Autorenkollektive bis 
zur Erprobung und Freigabe zentralisiert organisiert werden. In die Bestimmung der The- 
men und Ziele sind die verantwortlichen Fachkommissionen und wissenschaftlichen Bei- 
räte einzubeziehen. Die Lehrprogramme mussen sich in unterschiedliche Lehrkonzep- 
tionen einpassen lassen, der Hochschullehrer sollte sich seine Einsatzvariante ohne 


größeren Aufwand zusammenstellen können. 
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= Die Möglichkeiten des Lernenden, den eigenen Lernprozeß mit Hilfe des Systems be= 


wußt und eigenverantwortlich mitzugestalten, müssen in vielfältiger Weise erweitert 
werden (Zulassung von Aktionen, d. h. Anforderungen und Handlungen aus eigenem 
Antrieb; Angebot von Varianten usw.). 

- Die Lehrprogrammentwicklung ist ihrem Wesen nach ein schöpferischer Prozeß, der nicht 
allein auf wissenschaftlichen Theorien und Modellen beruht, sondern der praktischen 
Lehrerfahrung und des pädagogischen Geschicks der Autoren bedarf, Damit entzieht er 
sich einer durchgängigen Automatisierung, was aber nicht für jeden seiner Teile zutref- 
fen muß. Als eine Möglichkeit zur stärkeren wissenschaftlichen Fundierung der Lehrpro- 


grammentwicklung bietet sich das von OELSCHLEGEL in /5/ beschriebene Verfahren an. 


Die experimentelle Einführung von AOS VUZ/AP-64 an der TU Dresden schafft günstige 
Voraussetzungen für die in enger Kooperation mit dem Moskauer NIIVS durchzuführenden 
Untersuchungen zu effektiven Wirkungsbedingungen und Einsatzvarianten rechnergestUtzter 
Lehrsysteme im Ausbildungsprozeß. Der spezifische Beitrag des Forschungszentrums für 
technische Lehr- und Lernmittel wird vor allem darin bestehen, Beiträge zur Erarbeitung 
'präzisierter pädagogisch=technischer Anforderungen an Lehrsysteme, zur Schaffung einer 
Methodik der Lehrprogrammentwicklung und zur Ausarbeitung methodischer Einsatzempfeh- 
lungen für solche Programme zu liefern. Gleichzeitig sollen erste Schritte zur breiteren 
Nutzung von Lehrsystemen eingeleitet werden, wozu die Übergabe des Programmpakets 
AOS VUZ/AP-64 an interessierte Kooperationspartner gehören könnte. 

e 
An der TU Dresden soll das Lehrsystem zunächst in drei Lehrgebieten eingesetzt werden. 
Gemeinsam mit den verantwortlichen Lehrkollektiven wurden dafür folgende ‚Orientie- 


rungen festgelegt: ; 


Lehrgebiet Grundlagenmathematik: Entwicklung eines Lehrprogramms für Studenten mit 
spezifischen Wissens= und KönnenslUcken auf der Grundlage vorheriger diagnostischer 
Untersuchungen, Allmählicher Übergang zum Diagnostizieren während der Lehrprogramm= 


bearbeitung. 


Lehrgebiet Informationsverarbeitung im Maschineningenieurwesen: Erarbeitung eines Wie- 


derholungs- und Festigungsprogramms mit hohem Übungsanteil unter gezielter Nutzung 


2=40 
systemspezifischer Mittel zur syntaktischen Analyse von FORTRAN-=Elementen. Entwick- 
lung von Makros zur Auswertung bestimmter Aufgabenklassen und Untersuchungen zur mo= 
tivierenden Funktion des Lehrsystemeinsatzes für die Anwendung rechnergestUtzter Arbeits- 


weisen. 


Lehrgebiet Russische Sprache: Einsatz eines Übungsprogramms zu grammatikalischen Sach- 
verhalten (Gebrauch der Verbalaspekte) unter besonderer Beachtung differenzierter, lern- 
verlaufsabhüngiger Führung und Einschötzung des Lernenden sowie der Gestaltung informa= 
tiver Protokollübersichten für den Hochschullehrer, Entwicklung und Nutzung von Informa- 
tionsmöglichkeiten für den Lernenden (Wörterbuch, Übersetzungen, Hilfen usw.) und An- 
sützen der eigenverantwortlichen Übungsgestaltung. 

Der Einsatz des Lehrsystems AOS VUZ/AP-64 an der TU Dresden ist auch mit einigen 


Problemen verbunden, deren wichtigste in drei Punkten zusammengefaßt werden können: 


= Die vorhandene gerätetechnische Basis (max. 5 Endplütze verfUgbar) und deren hoher 
Auslastungsgrad erzwingen den Systemeinsatz ausschließlich im Selbststudium. Das ist 
zweifellos ein wesentlicher, aber nicht der allein denkbare und erfolgversprechende 
Einsatzort. 

= Die hohe Dynamik der gerätetechnischen Entwicklung macht langfristig getroffene Ent- 
scheidungen fur die Perspektive zumindest diskussionswurdig. Wurde vor 3 Jahren zu 
Recht auf das AP-64-Bildschirmsystem orientiert, steht heute die Frage seines baldigen 
Verschleißes und der Einführung leistungsfähigerer Mittel, darunter auch von Mikro- 
'rechnersystemen, 

= Der große Erfahrungsschatz der sowjetischen Hochschule bei der Lehrprogrammentwick- 
lung für AOS VUZ wird aufgrund unterschiedlicher Lehrplüne und -konzeptionen sowie 


des Zwangs zur Übersetzung nur bedingt nutzbar sein. 


Als Schlußfolgerung ergibt sich u. a., die Untersuchungen so anzulegen, daß ihre Ergeb- 
nisse weitgehend unabhängig von der konkreten technischen Basis und somit auf beliebige 
Lehrsystemarten Ubertragbar sind. Weiterhin wird es erforderlich sein, die aus der Lehr- 

geröteforschung gewonnenen Erfahrungen in dialektischer Weise aufzuheben und dabei die 


spezifischen Möglichkeiten rechnergestUtzter Lehrsysteme gebührend zu beachten. 
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KÜHNE , TORSTEN 


Rationelle Softwareentwicklung als Tehrgegenstand, in der 
Hochschul-Ingenieurausbildung 


(Kurzfassung) 


Bei der Beschreinbung,Bewertung und Rationalisierung von 
Problembearbeitungsprozessen typ« Ingenieurtätigkeiten 
gewinnt die | 

- Strukturierung und 

- Algorithmierung 

mittels effektiver Mittel und Methoden der automatenge- 
stützten Informationsverarbeitung eine zunehmend ent= 
scheidende Bedeutung zur meßbaren Erhöhung der Qualität 
und des Erneuerungsgrades sowohl materieller als auch 
geistiger Produkte, 

Betrachten wir uns kurz die. einzelnen Phasen des ingenteur= 
techn. Konstruktionsprozesses, die man folgendermaßen de- 
finieren kann. 


1. Spezifikationsphase (Funktionsfindung) 
2. Konzeptionsphase (Prinziperarbeitung) 
3. Gestaltungsphase (Gestaltung) 

4. Ausarbeitungsphase (Detalllierung) 


Anliegen der Automatenstützung des Konstruktionsprozesses 
ist, möglichst durchgängig alle Phasen im Rechner abzubil- 
'den(Einheit von Soft- und Hardware) und die Objekte rechner» 
‘systemintern zu manipulieren und zu bewerten. 

Der entsprechende Softwareentwurf int mit einem hohen Maß 

an Abstraktion verbunden, d.h. die Fähigkeit bei Betrachtung 
komplexer Systeme und Problemstellungen die wesentlichen von 
den unwesentlichen Seiten zu trennen, Es entsteht also die 
Aufgabe, das komplexe Gesamtsystem in hinreichend überschau- 
bare und verifizierbare Teilsysteme und Einzelprinzipien zu 
zerlegen, wobei die Schritte bei einer solchen 

« Dekomposition mit 

- Abstraktion 

auf unterschiedlichem Niveau verbunden sind. 
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Aufbereitete technologische Mittel zur Unterstützung dieses 
Prozesses werden in zunehmender doch bisher in unzureichen« 
der(was die 
- Auswahl 
- Präzisierung 
- Bündelung 
- durchgängige Anwendbarkeit auf sämtliche Phasen des Kon= 
struktionsprozesses 
betrifft) Weise durch die Informatik bereitgestellt. 


Technolog., Mittel 


Method. Mittel ee Mittel 


- Methoden - Programmsysteme 
- Prinzipien = Programme 

- prakt. Vorgehensweisen - Moduln 

- anwendungstechn. Forderungen = Makros 


Der systematische Einsatz der technolog,. Mittel ist beim 


“ Programming in the large 
einsichtig und unabdingbar, 


Die Absolventen unseres H5-Ausbildungsprozesses der techn. 
und ök. Fachrichtungen müssen jedoch in zunehmender Weise 
zur Beherrschung und Anwendung der Softwaretechnolog. 
Mittel befähigt werden woraus sich ergibt, an geeigneten 
-Prozessen und Objekten sowie Systemen innerhalb des wiss. 
geführten Studlenprozesses 

- Lern- und 

“ Träinings- 

strukturen mit den Bntsprech, Inhalten unter Einbeziehung 
bewährter hochschuldidaktischer Prinzipien zu realisieren, 
Somit ergibt sich die Aufgabe o.g. technolog, Mittel für 
den Studienprozess im Umfang des 

- Programming in the small 

aufzubereiten, wobei über die bisherigen Zielstellungen der 
vertieften IV-Ausbildung von Ingenieuren damit hinausgegan- 
gen wird. 


Za4a 
Softwaretechnolog. Fähigkeiten 


und Fertigkeiten : Forderung 
Dokumentations- Entwurfsmeth, : Realisierung 
unterstützung Mittel für 
von Programmen Softwareentw. 
bisher zunehmend erfäl. s Zeit 


Bei der Erarbeitung der Schwerpunkte bzgl. 'Entwurfsmethod. 

Lehrinhalte bilden | 

l. Relevante Inhalte und Relationen der Software-Technologie 
(Anwendung von Gesetzmäßigkeiten, Methoden und Werkzeuge) 

2. Aufgabenklassenbildung bzgl. ihrer Spezifika zu soft.ware- 
technolog. Komponenten 

3. Didaktische Grundpositionen und ergonomische Aspekte 


ein Forderungskonzept bzw. Bedingungsgefüge. 


Zu le 


- Strukturierter Entwurf (schrittweise Dekomposition Prozess- 
Objekt-bezogen) 
- Modularer Entwurf (- Funktionsbezogen 
- Systembezogen) 
- Prinzip der Konzentrierten Iogik (Anwendungsfall für Modul. 
Entwurf) 
- Aussagenlogik (formale Beschreibung von Entscheidungspro- 
blemen und deren Minimierung) 


zu 2. 


Vergleichende Untersuchung und Zuordnung von ingenieurtechn- 
Aufgabenstellungen bzgl. ihrer Dekomposition nach den be- 
kannten Softwareentwicklungsmethodens 

- Jackson - Methode 

- Warnier - Methode 

- Constantine - Methode 

- et 


prim. Darstellungsmethoden 
- SADT 


(x) 
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Zu Fe 

Aus der Realisierung der o.g. Inhalte und der Einbeziehung. 
eines automatengestützten 

= lehrsystemes mit ve 

interaktiver Arbeitsweise zur 

- Lehrprogrammerstellung durch 

- den Iehrer (Iehrprogrammautor) und 

- lLehrprogrammabarbeitung durch den/die 

- Studenten 


‚sowie den gleichzeitigen Einsatz des Rechners als 


- Arbeitsinstrument des/der Studenten ergeben sich wirklich- 
keitsnahe/praxisrelevante ‚Bedingungen zur Ausprägung von 
- Selbstständigkelt und Eigenverantwortlichkeit. 


Das Automatengestützte Lehrsystem A0OS = vuz(*) 

wird auf der Rechnerbasis ESER 1022 mit. AP 64 an der Hoch- 
schule für Architektur und Bauwesen Weimar zur Ausbildung 
der Studenten der Fachrichtung Bauingenieurwesen eingesetzt 
werden. 

Es bildet die Basiskomponente eines Automatengestützten 
Wrainings- Lehr- und Auskunfts- Systemes ATLAS. 


Die in Entwicklung befindlichen Trainings- und Lehrkomponen- 

ten werden durch eine | 

- Methodenbank (Auskunftssystem) mit entspr. 

- Nutzerführung ergänzt um den stud. Aneignungsprozess durch 
Komponenten des j 

- wiss. Arbeitsprozesses 
sinnvoll zu ergänzen und außerhalb der E-A-Aufgaben auch 
fachwiss. Forschungsaufgaben durch weitere 

- Nutzergruppen wirksam zu unterstützen. 


Literatur: Verfasser: 
Hartwig,WcH. Drerer.nat. Kühne, T 
Das lehrsystem SPOK-VUZ ‚Fo-Zentrum Hochschule für 
fürtechn. Lehr-und Lernmittel TUD Architektur und 


Schriftenreihe "'Informationsverarbeitung Bauwesen Weimar 
im Hoch- und Fachschulwesen 1981 


Dr. Lemke, Guntram 


Prexisorientierte Weiterbildung am Schulungszentrum des 
VEB Robotron-Anlagenbau, Leipzig. 


1. Einleitung 


Die effektive Nutzung der vom VEB Kombinat Robotron ver- 
triebenen Erzeugnisse (Hardware) und Leistungen (Software) 
setzt umfassende Kenntnisse im Bereich der Informationsver- 
arbeitung und der dafür eingesetzten Informationstechnik 
voraus. Die Hoch- und Fachschulen sowie die Berufsausbil- 
dung vermitteln im In- und Ausland das notwendige Grundwissen. 
Es ist durch spezielle Kenntnisse über die einzusetzenden 
Anlagen, Geräte, Systeme und Verfahren zu erweitern. Die 
Schulungseinrichtungen des VEB Kombinat Robotron bieten da- 
für ein umfassendes Schulungsprogramm. Dieses Schulungsange- 
bot wird ergänzt durch Lehrgänge für eine anlagen- und ge- 
räteunabhängige Aus- und Weiterbildung, um zur Deckung des 
sich bei den ünterschiedlichen Bildungsvoraussetzungen er- 
gebenden zusätzlichen Bedarfs beizutragen. 


2. Leistungsspektrum und -angebot 


Das Schulungsprogramm zeigt ein modular aufgebautes und 
zwischen den einzelnen Schulungseinrichtungen abgestimmtes 
Lehrgangssystem. Es ermöglicht den Käufern von Erzeügnissen 
und Leistungen des VEB Kombinat Robotron sowie den anderen 
Interessenten die individuelle Gestaltung des Bildungsweges 
der Mitarbeiter entsprechend den vorhandenen Kenntnissen 
und Erfahrungen. Besondere Anforderungen des künftigen 
Tätigkeitsbereiches können ebenfalls berücksichtigt werden. 
Damit ist ein optimales Verhältnis von Bildungsaufwand und 
dem zu erreichenden Wissensstand zu erzielen. 

Schrittweise konnte unter Beachtung der Anforderungen ein 
leistungsfähiges, modulares und mit anderen Schulungsein- 
richtungen des VEB Kombinat Robotron abgestimmtes Lehrgangs- 
system aufgebaut werden. Es hat sich bereits seit vielen 
Jahren bewährt und wurde durch ständige Weiterentwicklung 
den sich verändernden erhöhten Anforderungen angepaßt. 


2-47 


Das Schulungsangebot umfaßt Lehrgänge zur Aus- und Weiter- 
bildung von Spezialisten auf folgenden Gebieten: 
= Software 

Systemanalytiker 

Anwendungsprogrammierer 

Systemprogrammierer 

Operatoren 
- Hardware 

Anlagentechniker 

Reparaturtechniker 
Die Schulungseinricentungen sind jederzeit bereit, weitere 
Aus- und Weiterbildungswünsche zu erfüllen, die sich aus 
den besonderen Anforderungen an die Soft- und Hardware 
eines Käufers ergeben. Dafür werden individuelle Schulungs- 
abläufe zusammengestellt und Sonderlehrgänge konzipiert. 
Die Mitarbeiter der Schulungseinrichtungen für das Angebot 
von Schulungsleistungen und die Spezialisten der einzelnen 
Schulungsgebiete geben dafür die notwendige Unterstützung 
und beraten jeden Interessenten fachgerecht. 
Weitere Informationen sind den Schulungsprogrammen zu ent- 
nehmen, die auch mehrsprachig zur Verfügung gestellt werden. 


3. Schulungsdurchführung 


Das Schulungszentrum Leipzig des VEB Robotron-Anlagenbau 
übt im VEB Kombinat Robotron die Leitfunktion Schulung aus 
und koordiniert die Arbeit der anderen Schulungseinrichtun- 
gen im Kombinat. 

Die Umsetzung 'der Schulungskonzeptionen und des Lehrstoffes 
erfordert den Einsatz leistungsfähiger Hoch- und Fachschul- 
kader als Lehrkräfte. Die 170 eingesetzten Lehrkräfte sind 
anerkannte Spezialisten mit einem umfangreichen, durch prak- 
tische Arbeit gefestigten Wissen und mit pädagogischen Er- 
fahrungen. 


Besondere Anforderungen stellen die in jedem Lehrgang immer 
wieder auftretenden unterschiedlichen Bildungsvoraussetzun- 
gen der einzelnen Lehrgangsteilnehmer und ihre voneinander 
abweichenden Erwartungen an das Ihnen zu vermittelnde Wissen. 
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Die Lehrkraft muß daher sofort auf diese Bedingungen ange- 


‚messen reagieren, ohne das zu erreichende Lehrgangsziel zu 


gefährden. Das trifft in erhöhtem Maße auf die Lehrgänge. 
mit ausländischen Teilnehmern zu, da die sprachliche Ver- 
ständigung über Dolmetscher zusätzlichen Aufwand und ein 
ausgeprägtes Einfühlungsvermögen der Lehrkraft erfordert. 
Die zusätzliche Sprachqualifizierung und damit die Durch- 
führung von Lehrgängen in Fremäsprachen durch die Lehrkräf- 
te hat bereits zur Verbesserung der Situation ebenso beige- 
tragen wie das viel genutzte Angebot zu Konsultationen nach 
der eigentlichen Lehrgangszeit und die bereitgestellte um- 
fangreiche fremdsprachige Schulungsdokumentation. 


Ein Teil der theoretischen Lehrabschnitte wird auf Wunsch 
der ausländischen Partner in ihrem Land durchgeführt: Mitar- 
beiter des Schulungszentrums waren bereits auf allen fünf 
Kontinenten im Einsatz, haben sich unter oft komplizierten 


klimatischen sowie anderen landesabhängigen Bedingungen be- 
währt. 


4. Schulungsorganisation 


Die inhaltliche Vorbereitung und die Erfüllung der Schulungs- 
eufgaben erfordern: 


Mitwirkung in betrieblichen und überbetrieblichen, beraten- 
den und die Bildungsarbeit koordinierenden Gremien im In- 
und Ausland 

Beschaffung der für die Erarbeitung der Entwicklungskon- 
zeption des Schulungszentrums benötigten Informationen und 
Umsetzung der gewonnenen Erkenntnisse auf die Belange des 
Schulungszentrums 

Lang-, mittel- und kurzfristige qualitative und quantita- 


tive Planung des Schulungsbedarfs sowie der anzubietenden und zu 
erzielenden Schulungsleistungen 


Bilanzierung von Schulungsbedarf, Schulungskapazität und 
zu erbringenden Schulungsleistungen 
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- Erarbeitung jährlicher Lehrgangsterminpläne unter Berück- 
sichtigung der zeitlichen Schwankungen im auftretenden Lehr- 
gangsbedarf, der verfügbaren Lehrkräfte, Schulungsräume 
und -technik 


- Angebot der Lehrgänge an die in- und ausländischen Inter- 
essenten durch deutsch- und mehrsprachige Informations- 
schriften, Schulungsprogramme, Kundenberatung im In-und 
Ausland usw. 


- Disposition der Lehrgangsplätze bei Sicherung vorrangig 
zu erfüllender Schulungsverpflichtungen 

- Angebot und Abschluß der ausländischen Lehrgangstellnehmer 
während ihres Aufenthaltes in Leipzig 


- Berechnung und Analyse der erbrachten Schulungsleistungen. 
5. Schlußbemerkungen 


Die Vermittlung praxisorientierten und erprobten Wissens 
war und ist eines der wichtigsten Zeile der Arbeitdes Schu- 
lungszentrums, ebenso wie die Durchführung umfangreicher 
Praktika für die Lehrgangsteilnehmer. 

Großer Wert wird auf die zeit- und qualitätsgerechte Bereit- 
stellung der Schulungsdokumentation in den benötigten Spra- 
chen gelegt. Das ist oft nur unter hohem persönlichem Ein- 
satz der Lehrkräfte und der technischen Mitarbeiter zu er- 
reichen. Die bisherigen Erfolge rechtfertigen den Aufwand. 


Das Schulungsangebot des Schulungszentrums Leipzig umfaßt 
in Abstimmung mit der Absatzverantwortung des VEB Robotron- 
Anlagenbau hauptsächlich folgende Schulungsgebiete der 
Soft- und Hardware: 


- Elektronische Datenverarbeltungsanlagen 


- Mini- und Mikroechnersysteme, wie Bürocomputer, Basis- und 
Prozeßrechnersysteme 


Gerätesysteme und Einrichtungen zur Datenfernverarbeitung 
Anwendungslinien und Anwenderlösungen 


Systemunabhängige Lehrgebiete,. 5 


2-50: 


Das Lehrgangssystem ist so aufgebaut, deß es der zu er- 
wertenden Entwicklung von Soft- und Hardware entspricht, 
die Bildungsanforderungen erfüllt, die Qualifizierungs- 
zeit verkürzt und den Bildungsaufwand senkt. 


Anschrift des Verfassers: 


Dr. Lemke 
VEB Robotron-Anlagenbau 
1010 Leipzig 


Gerberstr. 3/5 
-Schulungszentrum 
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Mätzel, Klaus 


Einsatzergebnisse des >ystems PSU in der Ausbildung 


Mit dem Einsatz des Systems PSU werden für Aufgaben der 
'Programmentwicklung Möglichkeiten einer solchen sprachli- 
chen Schnittstelle angeboten, die sowohl im Stapel - als 
auch im interaktiven Betrieb genutzt werden kann und zudem 
einen einfachen Übergang zu unterschiedlichen Rechnersyste- 
nen gestattet. 


Aus der Sicht der Ausbildung bietet ein solcher Zugang 

einen besonderen Vorteil; zum einen können die methodischen 
Aspekte der problemorientierten Problemlösung unmittelbar 
auf die Rechnernutzung übertragen werden und andererseits 
wird die Ausbildung prexisrelevanter, wenn sich Ausbildungs- 
und Produktionsumgebung nicht unterscheiden. 


Prof. Dr. K, Mätzel 
Technische Hochschule Karl-Marx-Stadt 
Sektion Informatik 
9010 Karl-Marx-Stadt 
PSF 964 
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Klaus Ringhand 


PROTOS - Ein Hilfsmittel zum Entwurf reohnergestützter Bkono- 
mischer Spiele 


Reohnergestützte &konomische Spiele werden heute überwiegend. 
als Diealogprojekte entwickelt, 

Ein Problem beim Entwurf dielogorientierter ökonomischer Spie- 
le ist die Gestaltung der Aus- und Eingaben am Bildschirm. 

Hier treffen fachlich-inhaltiiche, pädagogisch-methodische und 
datenverarbeitungsteohnische Anforderungen aufeinander. Zur Lö- 
sung dieses Problems ist eine gute Kommunikation zwischen den 
Fachökononen als geistigem Vater des ökonomischen Spieles und 
dem Datenverarbeiter als dessen Realisator notwendig. Diese Kom- 
munikation wird durch das Softwarepaket PROTOS unterstützt, in- 
dem es die schnelle Entwicklung eines funktionsfähigen Prototyps 
des zukünftigen rechnergestützten 5konomilschen Spieles ermög- 
liicht. Der Prototyp gestattet es, die entworfenen Bilder in der 
festgelegten Reihenfolge zu betrachten. Dabei sind Eingaben in- 
haltlicher Art möglich, sie dienen zum Test der Gestaltung der 
Eingabefelder. Die Eingaben haben keinerlei Wirkung auf andere 
Dilder oder die Bildfolge. Eingaben zur Bildfolgesteuerung er- 
folgen durch Steuerzeichenkombinationen. 

Das Softwarepaket PROTOS wurde in Zusammenarbeit mit. der KMU 
Budapest in PASCAL entwickelt und auf einem Mikrorechner imple- 
mentiert., 
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Dr.-Ing. Alfred Schilling. 


Konzept der Lehrerweiterbildung in ee in Zusammener- 
beit mit_d dem Pädagogischen_K Kreiskabinett Leipzig=Süd 


In der-Ausbildung von POS- und EOS-Lehrern spielt die Infor- 
matik auch heute noch eine untergeordnete Rolle, da besten- 
falls Mathematik-/Physik- und ESP-Lehrer in unterschiedlich 
geringem Umfang darüber etwas hören. Im IV. Quartal 84 kommen 
die ersten Heimcomputer der DDR-Produktion in den Handel und 
mit der wachsenden Zahl solcher Geräte in den Familien werden 
in zunehmenden Maße auch die Lehrer mit Fragen zum Komplex 
Informatik konfrontiert werden. 

Ab Herbst 1995 werden in den 7. Klassen offiziell Taschenrechner 
statt Rechenschieber eingeführt. In diesem ZusammenBang‘ wird 
ein Plan zur Lehrerweiterbildung im Stadtbezirk Leipzig-Süd 
erarbeitet. Mit einem Kurs zur Einführung der Taschenrechner i 
im Herbst 84 läuft ein Plan zur Weiterbildung nicht nur für 
Mathematiklehrer an, der im weiteren auch den rationellen Ein- 
satz des Heimcomputers im Unterricht und die dazu notwendigen 
Grundlagen umfassen wird. 


Dr.-Ing. A. Schilling 
Karl-Marx-Universität Leipzig, ORZ 
"7olo Leipzig 

Karl-Marx-Platz 
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Simon, Ullrich 
Neef, Günther > 


Erfahrungen bei der Ausbildung von Studenten des MIW auf dem 
Gebiet der Informationsverarbeitung und Mikroelektronikanwendung 


1. Einleitung 


Die Entwicklung von Wissenschaft und Technik wird insbesondere 
seit den siebziger Jahren in hohem Maße durch neue Wissensge- 
biete geprägt, die zu revolutionären Veränderungen von Erzeug- 
nissen, Prozessen und Technologien führen sowie den Arbeitsin- 
halt von vielen Berufsgruppen zunehmend beeinflussen und ver- 
ändern. Die Entwicklung, Produktion und vor allem die Anwendung 
der Mikroelektronik zählen zu den Disziplinen, die sich inter- 
national in einem historisch kurzen Zeitraum zu Sohlüsseltech- 
nologien der Volkswirtschaft profiliert haben. In gleichem Maße 
dringt die Informatik in viele Bereiche des gesellschaftlichen 
Lebens ein und führt durch Übertragung von Aufgaben der Infor- 
mationsverarbeitung auf EDV-Anlagen zu weitrechenden Verände- 
rungen von der Industrie bie in den Dienstleistungssektor hin- 
eine 

Vor allem im Maschinenbau, der international mit zu den Schritt- 
maohern für die Anwendung der Informatik und der Mikroelektro- 
nik gehört, zeichnet sich langfristig eine durchgreifende In- 
tegration von mechanischen und informationellen Prozessen auf 
der Basis der Mikroelektronik ab, Die durch die bisherige Ent- 
wicklung bestätigten Prognosen weisen für den Haschinenbau eine 
zunehmende Anzahl von reohnergestützten Arbeitsplätzen mit in- 
teraktiver Dialogführung, die Einführung von Systemen der durch- 
gängigen Informationsverarbeitung, die bedienerarme Fertigung 
durch fldöxible Fertigungssysteme und flexible Nontagesystene 
mit Industrierobotern mit dem Fernziel des automatisierten, 
bedienerarmen Betricbes aus, Sowohl die Forschung zu diesen 
Aufgabenkomplexen als auch ihre zuklinftige Nutzung erfordern 
vor allem von den Hoch- und Fachschulkadern des Kaschinenbaues 
neben einem soliden fachspezifischen Wissen in zunehmendem Maße 
Fähigkeiten und Fertigkeiten im Umgang mit dem Computer und mit 
der mikroelektronischen Steuertechnik. 

Diese Entwicklungstrends führen zu neuen Anforderungen an die 
Aus- und Weiterbildung von Absolventen des Maschineningeniour- 
wegense 


2-55 
2. Anforderungsprofil an das MIW unter dem Aspekt der Informatik 
und Mikroelektronikanwendung 


‚Ausgehend von den internationalen Entwicklungsrichtungen des 
Maschinenbaues wurden durch den Beirat für MIW sowie in vielen 
Fachdiskussionen mit Vertretern der Praxis Anforderungsprofile 
für den Absolventen des MIW hinsichtlich der Informationsrver- 
arbeitung und der Mikroelektronikanwendung erarbeitet. Vorder- 
gründig standen hierbei die Zielstellungen, durch die Fähigkeit 
zum algorithmischen Denken die Einsatzmöglichkeiten und -formen 
für Mittel und Methoden der Informatik und der Mikroelektronik 
im Maschinenbau abzuschätzen, mit oder an Computern fachspezi- 
fische Aufgaben zu lösen und durch ein erforderliches Grund- 
legenwissen gemeinsam mit Spezialisten der Informatik und der 
Automatisierungstechnik interdisziplinär an Automatisierungs- 
lösungen für technische Prozesse mitzuarbeiten. Dazu sind den 
Studenten des MI# unter Beachtung von fachrichtungsspezifischen 
Anwendungsgebleten Kenntnisse Über Gebiete wie z.B. 
- Problemanalyse, maschinenbautypische Prozeßbeschreibung 
- Konfigurierung und Auswahl von mikroelektronischen Baugruppen 
und Geräten der Daten- und Steuertechnik 
- Programmierung von informationsverarbeitenden Strukturen, 
Softwaretechnologie, Auswahl und Anpassung von Software 
- interaktiv Mensch-Naschine-Dialog usw. 
zu vermitteln, \ 


3, Erfahrungen bei der Ausbildung von Studenten 


An der Sektion Fertigungsprozeß und Fertigungsmittel der Tech- 
nischen Hochschule Karl-Marz-Stadt werden Studenten in der Ver- 
tiefungsrichtung Fertigungsprozeßgestaltung/Informationsverar- 
beitung nach der Nomenklatur ASU 4a und in allen Fachrichtungen 
der Sektion in der Stufe ASU 4b ausgebildet, 

Da gegenwärtig die Vermittlung von Kenntnissen zur Informatik 
und Mikroelektronik im wesentlichen auf die Hochschulausbildung 
konzentriert ist, müssen größere Anstrengungen zum Erreichen 
der 0.g. Ausbildungsziele unternommen werden. Nach vorausge- 
gangenen Fachdiskussionen in Leitungsgremien der Sektion bogann, 
aufbauend auf dem Wissensstand aus der Lehrveransteltung "In- 
formationsverarbeitung", die Ausbildung mit einem 30 h unfas- 
senden Intensivkurs Über Mikrorechentechnik für die Studenten 
des HIN. 
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Zur Darstellung und Aneignung der abstrakten Abläufe in einem 
Mikrorechner wurde auf Basis des "Polycomputer 880" ein Prakti- 
kum aufgebaut. Dazu erhält jede Praktikumsgruppe (2-3 Studenten) 
eine maschinenbauorientierte Aufgabe, die selbständig bis zum 
Maschinenprogramm zu bearbeiten und im Praktikum abgearbeitet 
und getestet wird. In Bild 1 ist der Aufbau eines Praktikums- 
platzes aargestellt, 


Bild 1: Praktikumsplatz mit Polyoompüter 880 


Nach Durchführung der Ausbildung für 4 Matrikel wurden in Aus- 
wertung der Praktika folgende Erfahrungen abgehoben: 


= Die eigenständige Arbeit am Rechner fostigte die Kenntnisse 
und Fähigkeiten Über Aufbau, Funktionsweise und Nutzung von 
Computern. 

= Die exemplarische Bearbeitung eines Übungsbeispieles bis auf 
Assembler- und Maschinensprachniveau verdeutlichte die Pro- 
grammierungstechnik sowie die Funktion und die Nützlichkeit 
von problemorientierten Sprachen; für den Maschinenbaustuden- 
ten wurde die Informationsverarbeitung "transparent". 

- Die Erarbeitung der Programe für die Praktikumsaufgaben er- 
folgte nach softwaretechnologischen Aspekten in Anlehnung an 
eine in der Lehrveranstaltung entwickelte Demonstrationsauf- 
gabe. Mit dieser Lösung wurde im 1. Praktikum die Bedienung 
des Mikrorechners erlernt und durch selbständige schrittweise 
Abarbeitung die Funktionsweise verdeutlicht. 
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= Das Interesse und die Bereitschaft zur Mikroreohneranwendung 


wurde durch die eigene Tätigkeit angeregt. 

- Der hohe Aufwand an Praktikumsbetreuung kann nur durch eine 
entsprechende Zahl von Übungsleitern realisiert werden. Hierzu 
haben sich ca. 15 Mitarbeiter aus der Sektion qualifiziert. 


Aufbauend auf den erreichten Ergebnissen erfolgte ab 1984 eine 

Erweiterung dieser Ausbildung. Durch eine im 5. und 6. Semester 

stattfindende Lehrveranstaltung "Grundlagen der Mikroelektronik- 

anwendung im Maschinenbau" werden Kenntnisse und Fählgkeiten Über 

Mikroreohner, Softwaretechnologie, Mikrorechnerarbeitsplätze, 

Steuerungstechnik für Werkzeugmaschinen, Roboter und Prozeßab- 

läufe, Computergrafik, CAD/CAM-Systeme usw. vermittelt. Dazu sind 

60 h Vorlesung, 15 h Seminare und 30 h Praktikum vorgesehen, In 

Fortführung des Polycomputer-Praktikuns werden gegenwärtig in 

' analoger Form 

- ein Praktikum zur bildechirmorientierten Arbeit an einem Heim- 
bzw. Büroconputer 

- ein Praktikum an einer CNC-Steuerung (siehe Bild 2) und 

- ein Praktikum an einer Inäustrierobotersteuerung (siehe Bild 3) 

vorbereitet. 


Bild 2: CNC-Steuerung 
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Bild 3: Industrierobotersteuerung 


Zur Gewährleistung der erforderlichen Sicherheit arbeiten die 
Steuerungen CNC-H 645 und IRS 650 im Simulationsbetrieb, Für 
Praktikunsgruppen mit syntaktisch fehlerfreien Programmen be- 
steht die Möglichkeit der Abarbeitung ihrer Lösung auf Steuerun- 
gen mit angeschlossener Werkzeugmaschine bzw. mit funktionsfä- 
higem Roboter, 


Verfasser: Prof.Dr.sc.techn. U, Simon, TH Karl-Marx-Stadt 
Sektion Fertigungsprozeß und Fertigungsmittel 
9010 Karl-Marxz-Stadt, PSF 964 
Dr.-Ing. G. Neef, TH Karl-Marx-Stadt 
Sektion Fertigungsprozeß und Fertigungenittel 
9010 Karl-Marx-Stadt, PSF 964. 


Wegner, Klaus 


Weiterbildung auf dem Gebiet der Informationsverarbeitung:’ 
Ausgangssituation sowie Ziele, Erfahrungen und Probleme 
eines Weiterbildungszentrume 


1. Einleitung 


Als wesentliche Prämisse für den technologischen Fortschritt in 
einem Lande wird angesehen, daß die Zuwachsrate des Lernens grö- 
Ber sein muß als die Zuwachsrate des technologischen Wandels. 
Der rasche informationstechnologische Wandel, das Vordringen der 
automatisierten Informationsverarbeitung (AIV) in immer neue An- 
wendungsbereiche, sowie neue Prinzipien, Methoden und Techniken 
‚der Rationalisierung der geistigen Arbeit erfordern einen brei- 
ten Bildungsstand, der durch gezielte Weiterbildung zu erhalten 
und auszubauen ist. Oberstes Ziel eines solchen Lernverständnis- 
ses muß es ein, bei allen Werktätigen eine allgemeine Aufgeschlos- 
senheit und positive Grundeinstellung für die anstehenden tech- 
nologischen Veränderungen, die eine Umstellung von Organisations- 
strukturen, Arbeitsinhalten und Arbeitsabläufen benirken, zu ver- 
mitteln. Für Hoch- und Fachschulkader ist es überdies notwendig, 
die AIV, letzthin den Computer, als Problemlösungsinstrument zu 
verwenden. 


N 


Aus- und Weiterbildung an den Universitäten und Hochschulen unse- 
rer Republik sind euf die Bewältigung der anstehenden informe- 
tionstechnologischen Veränderungen ausgerichtet, genügen jedoch 
noch nicht in allen Positionen den künftigen Anforderungen. Ge- 
genstand vorliegenden Beitrages ist die Weiterbildung. Ausbil- 
dungsaspekte werden nur am Rande berührt. Ziel des Beitrages 
ist die Darlegung der Ausgangssituation, wie sie für den 
schrittweisen Aufbau eines Weiterbildungszentrums für Informe- 
tionsverarbeitung von Belang ist, sowie die Darlegung der Ziele, 
Erfahrungen und Probleme beim Aufbau eines solchen Weiterbil- 
dungszentrums an der Humboldt-Universität zu Berlin. 

Die Ausführungen stützen sich teilweise auf einen Beitrag zur 
INFO 84 /1/. | 
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2. Ausgangssituation 


Nach einer Untersuchung der Gesellschaft für Informatik aus dem 
Jahre 1982 werden bis 1990 in der BRD 65 % aller Beschäftigten 
AIV-Wissen benötigen /2]» Der Akzent der modernen Industriear- 
beit verlagert sich von der physischen Anstrengung hin zur Ver-: 
arbeitung von abstrakten Symbolen. Eine weitere Untersuchung 
dieser Gesellschaft (Mai 83) verdeutlichte, daß die Mehrheit 
der BRD-Bevölkerung eine ambivalente Einstellung zum Computer 
beeitzt, wobei jedoch Personen mit Arbeitserfahrungen mit dem 
Computer diesen in seinen Auswirkungen generell positiver beur- 
teilen als Personen ohne eolche Erfahrungen /3/. 


Es ist hier weniger der Raum zu diskutieren, inwieweit diese 
Auswirkungen für uns von Bedeutung eind und in welchem Tempo 
sich der informationstechnologische Trend, insbesondere die Ver- 
echmelzung von Datenverarbeitungs-, Textverarbeitungs- und Konm- 
munikationstechnologie zu integrierten Informations- und Kom- 
munikationssystemen, in unserer Republik vollzieht. Vielmehr ist 
ee erforderlich zu erkennen, daß die daraus resultierenden An- 
forderungen an die Aus- und Weiterbildung auf uns zukommen und 
daß auch unter sozialistischen Verhältnissen, die soziale Sicher- 
heit als ein weltweit beachtetes Kriterium gesellschaftlicher 
Überlegenheit garantieren, subjektives Beharrungsvermögen und 
zahlreiche Innovationswiderstände überwunden werden müssen. 


Die Rolle des subjektiven Faktors nimmt zu. In einer Gesell- 
schaft, in der die Entwicklungsprozesse bewußt und zielgerichtet 
reguliert werden, können gerade von diesem Faktor Impulse aus- 
gehen, die die (informationstechnologische) Entwicklung be- 
schleunigen und in die erforderliche Bahn lenken oder auch - 
kraft der Traditionen und Gewohnheiten der Werktätigen - bren- 
sen. Dae Wissen um die neuen Technologien stellt ein: bedeutendes 
Potential zur Gewährleistung ihrer Beherrschung und Akzeptanz 
dar. Angehörige hochqualifizierter Berufsgruppen, die heute 
nicht im entferntesten daran denken, daß Computer einen Teil ih- 
rer Arbeit bewältigen können (z.B. Ärzte, Juristen, Lehrer)‘ wer- 
den förmlich überfahren, wenn ihnen in den nächsten Jahren Ex= 
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pertensysteme (der 5. Rechnergeneration) als "Wisseneverstärker" 
gegenüberstehen, Die Zukunft der AIV hat bereits begonnen, und 


ist Aufgabe der universitären (Aus- und) Weiterbildung, den 


notwendigen Bildungsvorlauf zu schaffen. Diesbezügliche Anstren- 
gungen an den Bildungseinrichtungen der imperialistischen Hoch- 
burgen sprechen für sich (vgl. z.B. /4/). 


Für die in der AIV tätigen (und weiterzubildenden) Hoch- und 
Fachschulkader unserer Republik stellt sich die gegenwärtige Si- 
tuation in komprimierter Form wie folgt darı 


1. 


4’ 


2. 


Die Mehrheit der in der AIV tätigen Spezialisten (Informati- 
ker) besitzt keine solide Grundausbildung in der AIV. Es han- 
delt sich hier um Ausbildungsversäumnisse der 60er und frühen 
70er Jahre. 

Irgendeine artfremde Ausbildung und oft nur kurze Berufser- 
fahrung, aber offensichtliche Programmierbegabung, schienen 
eusreichend zu sein, um nach einer zweiwöchigen Ausbildung 
zum Erlernen einer Programmiersprache und nach vierzehntägi- 
gem Erwerb von Grundkenntnissen eines Betriebssystems Soft- 
ware-Entwicklung betreiben zu können. 

Mit der massenhaften Verbreitung von Mikroprozessoren, Büro- 
und Personalcomputern werden AIV-Kenntnisse unterschiedlichen 
Grades bei Nichtinfornatikern benötigt. Bereits gegenwärtig 
zeichnet sich ein Mangel bei "Bindestrich-Infornatikern" ab, 
das sind Fachspezialisten (Ingenieure, Betriebeswirteschaftler, 
Mediziner usw.) mit umfangreichen Kenntnissen der AIV bzw. In- 
formatik. Es zeigt eich immer deutlicher: 

Die Praxis benötigt vorrangig den Fachspezialisten mit Infor- 
matikkenntnissen und meniger den reinen Informatiker nit theo- 
retisch-abstrakter Spezialisierung (vgl. hierzu auch /5/). 


In den Betrieben und Einrichtungen fehlt es insbesondere an 
Praktikern zur Entwicklung rechnergestützter betrieblicher 
Informationssysteme. Fachwissen hat hier Vorrang vor Inforna- 
tikwissen. Die Integration von Informatik-Inhalten in die 


‘technische, naturwissenschaftliche und wirtechafteniesen- 


schaftliche Aus- und Weiterbildung wird insofern inner mehr 
zu einem Schnwerpunktproblem. Während bei einer Reihe von Aus- 
bildungsrichtungen die sog. Endbenutzerschulung (Handhabung 
von Standardanwendungsprogrammen und fachspezifischen Soft- 
warewerkzeugen, z.B. Methodenbanken) ausreichend ist, wäre 
z.B. für betriebliche Informationssysteme ein Studium Sozie- 
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listische Betriebswirtschaft mit Studienschwerpunkt Informa- 
tik wünschenswert. Wohlgemerkt, von Informatik - als Wissen- 
schaft von der Struktur, den Prinzipien, Methoden und Mitteln 
der AIV, unter besonderer Berücksichtigung des Organisations- 
aspektes - ist hier die Rede, nicht von irgendeiner Progran- 
mierausbildung und Vermittlung von Gerätebeschreibungen 
("Struktur- bzw. Systemwissen statt Faktenwissen" /1/). 


3. Während in den Betrieben und Kombinaten die AIV ständig neue 
Anwendungsgebiete erschließt und günstige rechentechnische 
Voraussetzungen bestehen (Gleiches gilt für einige Weiterbil- 
dungseinrichtungen), können im MHF-Bereich die rechentechni- 
schen Voraussetzungen für eine hocheffektive Aus- und Weiter- 
bildung sowie (Grundlagen-) Forschung auf dem Gebiet der In- 
formationsverarbeitung nicht immer voll befriedigen. Da uni- 
versitäre Weiterbildung vorrangig mit Vermittlung neuester 
wissenschaftlicher Erkenntnisse zu tun hat und dabei zwangs- 
läufig auf die aus der Grundlagenforschung abgehobenen Ergeb- 
nisse mit applikativem Charakter zurückgreifen muß, ergeben 
sich ernsthafte Probleme bei der Gewährleistung des Bildungs- 
vorlaufs durch die Hochschulforschung. 


3. Ziele, Erfahrungen und Probleme beim schrittweisen Aufbau 
eines Weiterbildungszentrums für Informationsverarbeitung 


ziele: 


Durch Ministerweisung übernahm die Humboldt-Universität zu Berlin 
ab Sept. 1982 die Funktion einer territorialen Leiteinrichtung 
für die Weiterbildung auf dem Gebiet der Informationsverarbei- 
tung. Gleichzeitig wurde am Organisations- und Rechenzentrum der 
Humboldt-Universität mit dem schrittweisen Aufbau eines Weiter- 
bildungszentrums für Informationsverarbeitung begonnen. Damit 
soll ein wirksamer Beitrag zur raschen Verbreitung neuester Er- 
‘kenntnisse geleistet werden. 


Die Weiterbildung wird von mehreren Struktureinheiten der Hun- 
boldt-Universität - unter Federführung der ORZ - getragen und 
von weiteren wissenschaftlichen Einrichtungen der Hauptstadt un- 
terstützt. Dae Weiterbildungsprogramm wird im Juni eines jeden 
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Jahres an die interessierten Betriebe und Einrichtungen versen- 

det. Das Programm überstreicht folgende Gebiete; 

= Grundlagen der AIV 

- Gestaltung automatisierter Informationssysteme 

- Anwendung und Entwicklung von Betriebssystemkomponenten 

= Moderne Programmiereprachen, -umgabungen, -werkzeuge und 
-nethoden 

- Dialogsystene 

- Verfahrensorientierte Programmsysteme 

- Aufbau und Nutzung von Datenbanken 

- Nutzung ausgewählter Systeme der Klein- und Mikrorechentech- 
nik 

- Rechnergestützte Arbeitsplätze für ausgewählte Aufgabentypen 

- Grafische Datenverarbeitung 

- Datenkommunikation 

Neben der raschen Verbreitung praxisrelevanten AIV-Wissens (zZ. 

B. Nutzung funktions- und anwendungsorientierter Software) und 

neuer Entwicklungsrichtungen (z.B. "Büroautomatisierung”, 1lo- 

gische Programmierung) soll künftig die Vermittlung von mehr 

Theorie eine Schlüsselstellung bei der Arbeit des Weiterbil- 

dungszentrunms einnehmen. Oft ist es gerade der Mangel an Theo- 

rie, der die in sich hochdifferenzierte Praxis der AIV eo schwer 

veretehbar und überechaubar macht sowie die notwendige Kommuni- 

kation und Kooperation erschwert /1/. Für. die universitäre Wei- 


terbildung eröffnet sich hier ein breites Betätigungefeld, 


Dominierende Organisationsform der Weiterbildung ist der Lehr- 
gang (einwöchig, zweimöchig; meist aber ein Tag/Woche, eich 
über mehrere Wochen erstreckend). Mit Beginn dee Jahres 1985 
erscheint zur Unterstützung der Weiterbildung eine Heftreihe 
“Informatik-Skripten” in loser Folge. 


Erfahrungen: 


während im Studienjahr 1982/83 lediglich vier Lehrgänge nit ins- 
gesamt 138 Stunden und 105 Teilnehnern realisiert werden konn- 
ten, sind es im Studienjahr 1984/85 bereits 26 (angebotene) 
Lehrgänge mit inegesanmt 525 Stunden und 510 (angemeldeten) Teil- 
nehnern. 15 % der Teilnehmer sind promovierte Kader. 


Begehrt sind die Lehrgänge für neue Programniersprachen, Soft- 
waretechnologie und vor allem Büroautomatisierung/Bürocomputer. 
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Bei letzteren konnten nicht alle Anmeldungen berücksichtigt wer- 
den. Gleichwohl muß hierzu festgestellt werden, daß die Ausbil- 
dung/Uaschulung für neue Hard- und Softwaresystene, inklusive 
Programniersprachen (z.B. BASIC), nicht primäres Ziel der uni- 
vereitären Weiterbildung sein kenn, zumal bis 1990 nur 4 % des 
Hoch- und’ Fachschulkaderbestandes der DDR an den Universitäten 
und Hochschulen weitergebildet werden können /6/. Sofern Pro- 
gramnlereprach-Lehrgänge durchgeführt werden, geht es hier pri- 
när um die methodischen Aspekte einer Sprache (also nicht um 
“programming in language”, sondern um "programming into lan 
guage”). 


p preblenanaosı 


Den Hauptanteil der Weiterbildung tragen gegenwärtig das ORZ 
der Hunboldt-Universität und das ORZ der Hochschule für Okono- 
mio. Überwiegend wissenschaftliche Mitarbeiter - und nicht 
Hochschullehrer - fungieren als Lehrkräfte. Dieser Zustand kann 
nicht befriedigen. Indes: Die Einbeziehung der die Weiterbil-. 
dung mittragenden Sektionen bereitet Schwierigkeiten, auch wenn 
die dort vertretenen Lehrgebiete in unmittelbarer Nachbarschaft 
der Informatik angesiedelt sind. Zwar bietet die Humboldt-Uni- 
versität mit ihrem breitgefächerten Wiesenschaftespektrum nahe- 
zu ideale Voraussetzungen für eine breitangelegte, annendungs- 
orientierte Informatik-Weiterbildung (im Sinne einer "Binde- 
strich-Informatik”), jedoch ist interdieziplinäre Weiterbildung 
eben mehr ale die bloße Aneinanderreihung von Weiterbildungs- 
maßnahmen verschiedener Wissenschaftedisziplinen. Auch fehlt es 
z.Z. noch an interdieziplinärer Forschung, die für die Lösung 
sowohl komplexer wissenschaftlicher Probleme der Grundlagenfor- 
schung als auch der angemandten Forschung geeignet ist. Der Zu- 
sammenhang zwischen wissenschaftlicher Forschung, insbesondere 
anwendungsorientierter Grundlagenforschung, und Weiterbildung 
muß noch stärker ale bisher erkannt werden. Nicht zuletzt er- 
weist sich Weiterbildungstätigkeit als besonders forschungs- 
fördernd. 


4. Schlußbemerkungen } 


Kontinuierliche Weiterbildung ist notwendig für die Beherr- 
schung und Akzeptanz der neuen Technologien. Die Humboldt-Uni- 
versität kann neben umfassenden Weiterbildungsaktivitäten auf 
dem Gebiet der Mikroelektronik (vgl. /6/) nunmehr auch auf er- 
ste Erfahrungen bei der Weiterbildung auf dem Gebiet der Infor- 
mationsverarbeitung verweisen. Damit wurde ein wesentlicher Bei- 
trag zur raschen Verbreitung praxisrelevanter Kenntnisse einer 
Schlüsseltechnologie geleistet, zumal die Anwendung der Mikro- 
elektronik primär vermittele Informationvverarbeitung =rfolgt 
(Anschlußtechnologie). Insgesamt bedarf es jedoch noch erhebli- 
cher Anstrengungen, um die Weiterbildung in Zukunft gleichran- 
gig neben die Aufgaben in der Ausbildung und in der Forschung 
zu setzen. Weitere Anstrengungen sind notwendig bei der Inte- 
gration von Informatikinhalten in die Fachausbildung. 


Literatur, 


- 


/3/ NH. Lehmann, R. .Tschirschwitz, K. Wagner: Einige Erfahrun- 
gen und Schlußfolgerungen zur Weiterbildung auf dem Gebiet 
der Informationsverarbeitung; in: INFO 84, Dresden 6.-10.2. 
1984, Bd. 2, S. 158-162. 


/2/ I. Twiehaus: Berufsbilder und Anforderungen in der Daten- 
verarbeitung im Wandel; in: Office Management 7-8/1984, 
S “ 659-661 . 


/3/ K. Lange: Das Image des Computers in der Bevölkerung; 
’ in: GMD-Spiegel 2/1984, S. 52. 


/4/ H.R. Hansen: Mikrocomputer in der US-amerikanischen Hoch- 
schulauebildung; in: Angewandte Informatik 26 (1984)11, 
5 [} 443-451 . 


/5/ H. Müller-Merbach: Informatikausbildung für die Zukunft; 
in: Angewandte Informatik 26(1984)2, S. 66-67. 


/6/ B.P. Nerlich, K. Albrecht: Weiterbildung an Universitäten 
und Hochschulen - Zur postgradualen Bildung vpn Hochschul- 
kadern an der Humboldt-Universität zu Berlin; 


in: Das Hochschulwesen 32(1984)12, S. 328-330. f 


Verfasser: Dr. Kıaus Wagner 
Beauftragter für Weiterbildung 
Organisations- und Rechenzentrum der Humboldt-Uni- 
versität zu Berlin \ 
1086 Berlin, PSF 1297 


SEKTION 3 
Relationale Datenbasen 


Aden, Horst 


Abschätzung der erforderlichen Anzahl von Direktzugriffen zur 
Komplettierung von Daten 


1. Einleitung 


Diesem Beitrag liegen Vorbetrachtungen zur Entwicklung des List- 
generators für das Programmsystem VIV aus dem Jahre 1973 zugrun- 
de. Da es bei Anwendern, Projektanten, sogar Programmierern oft 
em Verständnis für die aus den Anforderungen resultierenden 
Hauptspeicher- und Zugriffsproblenen mangelt, sollen diese Be- 
trachtungen doch noch veröffentlicht werden. Sie eind sicher 
euch für Datenbankaufgaben von Intereese, 


2. Abschätzung der zur Komplettierung einer Hauptgruppe er- 
forderlichen Sätze 


Geht man von der Annahme aus, daß Datensätze mit N relevanten 
Ordnungsbegriffen auszugeben sind und jede Gruppe die gleiche 
Anzahl von a Untergruppen enthält, so ergibt sich die Gesant- 
zahl e unterechiedlicher Schlüssel einer Hauptgruppe zu: 


N n=1 N 
s =)_ a = KR 9 (2.1) 
ne1 a=- 1 


Die Anzahl der Ergänzungssätze e, zum Beispiel Texte aus einer 
Nomenklatur, die zu jedem der a3 


Datensätze einer Gruppe zu beschaffen sind, beträgt damit 


N 
2>0.= a z — >21 fürepı (2.2) 
= nd a = 


Mit a «e 2 ergibt sich der ungünstigsete Fall, bei dem jede Gruppe 
nur zwei Untergruppen bzw. Sätze enthält. Vier Ordnungsbegriffe 
und a = 2. führen zu folgender Schlüsselhierarchie: 


1. 2. 3. 4. Ordnungsbegriffsstufe 
_— zen 8 Sätze (A2.1) 
— — 
Rn m — 
„0 2} 22 23 ‚, Schlüssel 


3-2 
Die Anzahl ‘der je Datensatz erforderlichen Ergänzungssätze be- 
trägt für dieses Beispiel 15/B. 
Folgende Tabelle verdeutlicht die Abhängigkeit der Anzahl von 
Ergänzungssätzen e je Datensatz in Abhängigkeit von der Anzahl 
der Sätze je Gruppe a für große N: 


8 2 3 4 5 6 10 (T2.1) 


1,5 1,33 1,25 1,2 1,1 


Wie allgemein bekennt und aus der Darstellung (A2.1) ersicht- 
lich ist, wird die überwiegende Anzahl von Ergänzungssätzen 

auf der niedrigsten Ordnungsbegriffsstufe gebraucht. Allgemein 
ist der Anteil der Ergänzungssätze aus der n. Ordnungsbegriffs- 
stufe: Ri 


on x (a - 1)a Sehne) mit aN>> ı (2.3) 


Die Abhängigkeit der erforderlichen Ergänzungssätze für die 
drei niedrigsten von fünf Ordnungsbegriffsstufen und verschie- 


dene Anzahlen von Sätzen bzw. Untergruppen zeigt die Tabelle 
2.2, 


en 


(N = 5) (T2.2) 


3, Abschätzung der zur Komplettierung bezüglich eines Ordnungs- 
begriffe erforderlichen Zugriffe 


Da die Ergänzungesätze gewöhnlich geblockt sind, ist zu erwarten, 
daß nicht für jeden dieser Sätze ein Zugriff erforderlich ist. 
Die Wehrscheinlichkeit dafür, daß mehrere unmittelbar benötigte 
Ergänzungssätze in einem Block gefunden werden, so daß nicht je- 
der einzeln geladen zu werden braucht, hängt von der Anzahl der 
Blöcke je Nomenklatur b, der Obereinstimmung der Sprtierungen der 
Daten- und Ergänzungssätze nach ihren Schlüsseln und der Vertei- 
lung der geforderten Ergänzungssätze Gber die Nomenklatur eb. 
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Im folgenden setzen wir eino Gleichverteilung voraus. Die Wehr- 
scheinlichkeit zwei Ergänzungssätze in einem Block zu finden, 
ergibt sich bei unterschiedlicher Sortierung zu: 


W2U = (3.1) 
b 


Die Wahrscheinlichkeit zwei Ergänzungssätze, die wie die _ 
Schlüssel in den Datensätzen sortiert sind, in einem Block zu 
finden, 138t sich folgendermaßen ableiten. Befindet sich dor 
erste zweier Ergänzungssätze in einem Block, so kenn sich der 
zweite nur im selben oder einem der folgenden Blöcke befindon. 
Die Gesamtanzehl der Fälle ergibt eich damit zu 


n-bben (3.2) 
nei 

von denen b Fälle zwei Sätzen in einem Block anteprechen. Da- 
mit ergibt sich die Wehrscheinlichkeit dafür, daß zwei Ergän- 
zungssätze bei gleicher Sortierung in einem Block gefunden 
werden, zu 


W2S = 
b+1 


(3.3) 


worin b>1 die Anzahl der Blöcke der Nomenklatur ist. 

Folgende Tabelle verdeutlicht die Abhängigkeit der Wahrschein- 
lichkeiten W2U und W2S von der Anzehl b der Blöcke einer No- 
menklatur. 


0,33 0,25 0,2 0,14 0,11. 0,05 


(T3.1) 


0,4 0,33 0,25 0,2 0,1 


4. Zusammenfassung und Schlußfolgerungen 


Während man bei der rein sequentiellen Datenverarbeitung mit 
zwei bis drei Dateien und Blockungsfaktoren von zehn mit etwa 
.0,2 bis 0,3 Zugriffen pro Ergebnissatz auskommt, vervielfacht 
sich die Anzahl der Zugriffe, falls nichtsequentielle Kom- 
plettierungen erforderlich werden, bis auf Werte von 1 bis 2 
Zugriffen je Datensatz. Dementsprechend erhöhen sich die Lauf- 
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zeiten. Diese krasse Vervielfachung der Zugriffe wird in der 
Praxis auf Grund der ungleichen Verteilung der geforderten Er- 
gänzungssätze, die effektiv einer Reduzierung der Nomenklatur- 
blockanzahl gleichkommt, selten erreicht. Der Sachverhalt 
macht trotzdem zugriffsreduzierende Maßnahmen erforderlich. 
Dazu zählen: 


Reduzierung der Anzahlen der Blöcke der Nomenklaturen, ins- 
besondere der zu erwartenden rangniedrigsten durch kompri- 
mierte Informsetionen wie zum Beispiel kurze Texte und Bit- 
vektoren 

vollständiges oder selektives Laden der Ergänzungssätze 

zum rangniedrigsten Ordnungsbegriff in den Hauptspeicher 
(b=1) 

vollständiges oder selektives Laden der Ergänzungssätze aus 


. kleinen Nomenklaturen zu möglichst rangniedrigen Ordnungsbe- 


griffen 

Kompression der benötigten Ergänzungssätze auf Arbeitsspei- 
chorn (Reduzierung von b) 

Beachtung der Sortierung (kleiner Effekt) 

Anlage von zwei Puffern zumindest für die rangniedrigeren 
Ordnungsbegriffe und geordnete Eingabe der Nomenklaturblöcke 
im voraus mit einem Minimum an Armbewegungen (gepufferte, 
gekettete Eingabe) 

Wenn es die Aufgabenstellung erlaubt, sollten die umfang- 
reichsten Ordnungsbegriffe den höchsten Sortierrang in den 
Datensätzen erhalten. 


Mit dem erwähnten Listgensrator wurden in 100 k HS etwa 0,65 
Direktzugriffe zu Ergänzungsinformationen pro in den Listen 
verwendeten Datensatz erreicht. 
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Dr. Buchholz, Bernd 
PILOT - eine Hehrtupelnohnittstelle für dan Datenbankbetriebs- 
system TOPAS 5 
1: Quellen 
Die Datenmanipulationssprache PILOT (programming interfaoe 
language for TOPAS) wird als universelle autserfreimdliche 
Hehrtupelschnittstelle angesehen. 
Falkenberg (/1/) stellt für die Entwioklung künftiger Daten- 


‚manipulationsspraohen folgende Forderung auf: 


"Erstrebenswert ist, daß diejenigen Regeln, die hEufig auf- 
treten, deskriptiv formuliert werden können. Andersrseitn ist 

es aber wegen der großen Vielfalt möglicher Regeln unzweckuäßig 
eine rein deskriptive Sprache vorzunehmen. Dio Einführung pro- 
zeduraler Elemente verhindert einerseits, daß die Sprache zu 
unhandlich wird und garantiert andererseits die Formulierbar- 
keit auch beliebig komplexer und ausgefallener Regeln". 

Als die am häufigsten in Datennanipulationssprachen auftretenden 
Regeln sind Anweisungen zur Hanipulation der Daten in der Daten- 
bank anzusehen. Es wurden deshalb zur Gestaltung der Syntax dor 
Mehrtupelschnittstelle Konstruktionen der Datenmanilulations- 
sprache SEQUEL (/2/) herangezogen. 

SEQUEL wird zu den abbildwngsorientierten Datennmanipulations- 
sprachen gezählt. Besonderer Wert wurde beim Entwurf dieser 
Sprache auf leichte Handhabbarkeit, gute Strukturierung und 

hohe Nutzerfreundlichkeit gelegt. 

SEQUEL, als relational vollständige Sprache, ist sowohl eigen- 
ständig mit recht großen Leistungsumfeng, als auch in ein 
PL1-Programm oingebettet, nutzbar. 

Um den Nutzer von der Erlernung der Programmiersprache PLi 

zu befreien, wurde in der Sprache PILOT auf den vollständigen 
Leistungsumfang von PLi1 bewußt verzichtet und dafür eine 

Auswahl von Steusrelementen problemorientierter Programmier- 
sprachen in der Notation der Entwurfssprache "Pseudooode" 

(/3/) aufgenommen. 

Da in PILOT keine Bezugnahme auf die konkrete Datenbank existie- 
ren, ist PILOT eine allgemein nutzbare Sprache auf Mehrtupel- 
basis für das Datenbankbetriebssystem TOPAS. 
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PILOT enthält deskriptive Sprachanweisungen zur Datenmanipu- 
"lation, zur Recherche, zur Ein- und Ausgabe von Variablen und 
gun Anschluß von Butzerprogeduren sowie prozedurale Sprach- 

elenente zur Programnmsteuerung. 

Der Nutzer dieser Sprache ist von der Kenntnis der Zugriffs- 
hilfen und der konkreten Datenformate der Attribute der 
Relationen befreit (/4/). 

Die Implementierung erfolgte mittels des Dresdner Progranmn- 
transformationssystens DEPOT (/5/). 


2. Formulierung einfacher Retrieval-Anforderungen 
Aufgrund der Konstruktion der Sprache PILOT kann sich der 
Hutzer die Sprachelemente stufenweise aneignen. Bereits 
mit minimalen Kenntnissen sind wmfangreiche einfache Retrie- 
val-Anforderungen leicht und effektiv formulierbar. 
Zur Demonstration seien zunächst zwei Relationen mit folgen- 
den Aufbau eingeführt; 
Relationsmame: STAM 
Attribute; AKTHR (Aktennunmer) 
R AHHDAT (Anmeldedatun) 
PATART (Patentart) 
Relationsnanes ERFD 
Attributes EAKTHER (Aktennummer) 
ENAHME (Erfindernane) 
GESCHL (Geschlecht) 
GEBDAT (Geburtsdatum) 
Grundlage der Formulierung von Retrieval-Anforderungen 
bilden die rekursiv anwendbare FIHD-Anweisung und die Ausgabe- 
enweisung PU?R. 
Beispiel: Ermittlung der weiblichen Erfinder, die jünger 
als 30 Jahre sind und nach dem 01.01.1980 ein 
Ausschließungspatent angemeldet haben. 


FIND AKTNR 
FROM STAM 
WHERE ANMDAT> 800101 AND PATART='A' 
FIND ENAME 
FROM ERFD 
WHERE EAKTNR=AKTNR AND GESCHLa'W! 
AND GEBDAT< 07.10.54 
PUT ENAME 
ENDFIND 
ENDFIND 


3. Datenmanipulationsmöglichkeiten 
Manipulationen innerhalb der Relationen sind mittels PILOT 
in. vielfältiger Weise möglich. Tupel können eingefügt oder 
gelöscht, Attributausprägungen verändert, Relationen um 
Attribute erweitert oder reduziert sowie Relationen angelegt 
und aufgegeben werden, . 
Beispiele: a) Füge ein Tupel mit der Aktennummer 1234567 
und dem Anmeldedatum 6.12.83 in die 
Relation STAM ein. 
INSERT AKTNRe1234567, ANUDAN=831206 
INTO STAM 
(Bem.: Die Ausprägung des Attributes PATART 
in diesem Tupel wird mit 'B' initialisiert. 
Das Anmeldedatum ist auch in der Form 
06.12.83 formulierbar.) 

b) Ändere die Patentart der Erfindung mit der 
Aktennummer 1234567 auf "Wirtschaftspatent" 
('#’). 

UPDATE PATART='!1' 
IN STAM 
. WHERE  AKTHR=1234567. 

c) Erwsitore die Relation STAM um die Attribute 
"Patentschriftnumner", und "Seitenzahl der 
Patentschrift" (SEITEN). 

EXPAND STAU: 
PSHR LIKE AKTHR 
SEITEH INT (3) 
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4. Ein- und Ausgabeanweisungen 
Mittels der in PILOT enthaltenen Ein- und Ausgabeanweisun- 
gen sind die Verarbeitung sequentieller Dateien, die Er- 
stellung von Druck- bzw. Bildschirmausgaben und die Eingabe 
von Verarbeitungsdaten (Parameter) während der Programmaus- 
führung möglich. Somit ist PILOT u.a. sowohl zur Erstellung 
von Aktuallsierungsprogrammen für Relationen, für die Her- 
stellung sequentieller Auszlige aus der Datenbank zur Weiter- 
verarbeitung mittels eines Tabellengenerators oder in anderen 
Projekten, ale auch die Erzeugung beliebig komplizierter 
Listen nutzbar. 
Beispiel; Ermittle die Aktennummern derjenigen Erfindungen, 
j die in vorzugebenden Berichtszeiträumen angemeldet 
wurden. 
DECLARE BZR INT (6) 
BIS INT (6) 
ENDDCL; 
WHILE EVEN DO 
GET BZR,BIS; 
PIHD AKTNR 
FROM STAM 
WHERE ANHDAT 2 BZR AND ANMDAT <BIS 
PRINT SKIP, 'AKTHR=',X(1),AKTHR 
ENDFIHD 
EHDWHILE 
(Ben.: Die PRINT-Anweisung kann durch PUT AKTHR ersetzt 
werden, da damit das gleiche Druckbild erzeugt wird. Die 
geforderte Eingabe (SYSIN) wird durch die SYSPRINT-Aus- 
gabe "PLEASE,GET BZR,BIS" signalisiert. Die Eingabe hat 
‚die Form: z.B.s BZRe840101, BIS=841007;) ö 


5. Sonstige Anweisungen 

PILOT enthält eine Reihe von prozeduralen Anweisungen zur 
Projektsteuerung, deren Semantik mit den entsprechenden 
Anweisungen in problemorientierten Programmiersprachen 
vergleiohbar ist. Zur Erhöhung der Effektivität der PILOT- 
Programmierung wurden eine Reihe von Builtin- Funktionen 


inplementiert. 
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Insbesondere zur Unterstützung der PLi- Anwendungsprogrammierer 
wurden Möglichkeiten geschaffen, PLi- Quelltext einzufügen 
sowie PLi- Prozeduren aus PILOT- Programmen aufzurufen. 

PILOT enthält eine Datenschutzfunktion auf Attributebene. 
Während der Abarbeitung von PILOT- Programmen entsteht ein 
Laufprotokoll sowie Statistiken der angeschlossenen Rela- 
tionen. Im Falle von E/A- Fehlern endet das PILOT- Programm 
mittels spezieller USER-ABEND-Codes. Somit sind PILOT- Pro- 
gramme auch unter Jobnetzsteuerung nutzbar. 


6. Systemtechnische Voraussetzungen 

Es gelten die zur Nutzung des Datenbankbetriebssystems TOPAS 
einzuhaltenden Voraussetzungen (/6/). Zur Übersetzung eines 
PILOT- Programmes ist ein Hauptspeicherbereich von 200 K Bytes 
erforderlich. 


7. Abarbeitung von PILOT- Programmen 

Zur Abarbeitung von PILOT- Programmen stehen die drei Proze- 
duren PILOTC, PILOTCL und PILOTCLG zur Verfügung. 

Ergebnisse sind bei der Butzung von PILOTC der PLi- Quelltext 
mit vorübersetzten Makros, von PILOTCL der ausführbare Lade- 
modul und von PILOTc1g die Ergebnisse des Programmes. 

Die einzelnen Abarbeitungsschritte sind in der Abbildung 1 
dargestellt. 
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Höllering, H.-H.; Schober ‚K. 


Aufbau von Auskunftssystemen auf der Basis relationaler 
Datenbanken 


Eine der Hauptaufgaben der Arbeit an den Rechenzentren des. Be- 
reiches des MHF besteht darin, die zentral gespeicherten Daten- 
fonds der Hochschulverwaltung unmittelbar am Arbeitsplatz des 

zuständigen Sachbearbeiters verfügbar zu machen. Als hardware- 
mäßige Voraussetzungen dazu stehen relativ leistungsfähige Da- 
tenverarbeitungsanlagen der ESER-Reihe zur Verfügung (ES 1040). 


Zur Lösung der oben beschriebenen Aufgabe gibt es verschiedene 
technische und technologische Möglichkeiten. Eine davon, die wir 
weiter verfolgt haben, ist der Anschluß von fernaufgestellten 
Bildschirmgeräten über die notwendige Hardware an unseren Zentral- 
rechner ES 1040. Der Engpaß dieser Variante ist bekanntermaßen 

das Einrichten von Standleitungen durch die Deutsche Post, aber .,. 


- verfügt das ORZ über fernaufgestellte ES 7920 und ES 7925, 
und man kann hier testen (d. h. Sachbearbeiter kann auch 
‚im ORZ die BS-Technik nutzen) und 


- ist der Engpaß in der Perspektive sicher abbaubar. 


In der Perspektive werden auch Bürocomputer (BC)-Lösungen ange- 
strebt, jedoch hängt dieses letztlich von der Verfügbarkeit ent- 
sprechender Hard- und Software ab. 

Perspektivisch geht es um den Entwurf komplexer rechnergestütz- 
ter Informationssysteme (kurzsRIS) unter Nutzung zentraler und 
dezentraler Rechentechnik am Arbeitsplatz, um die Vorteile bei- 
der Technologien auszunutzen und die Nachteile auszugleichen. 
Neben der unmittelbaren Verfügbarkeit der Datenfonds für Daten- 
verwaltungsprozesse des Sachbearbeiters wurde erstmalig ange- 
strebt, einfache Anfragen im Dialog zu realisieren, also Daten“ 
verwaltungs- und Auskunftssysteme zu konzipieren, 


Die Voraussetzungen dazu sind bei uns durch das Datenbankbetriebs- 
system (kurz: DBBS) "MIMER'" gegeben, das vielen Nutzern bereits 
bekannt ist. Dieses System gestattet den Aufbau und die Verwal- 
tung von Datenbanken, sowohl im Stapel als auch im Dialog, und 
ermöglicht die wenig aufwendige Programmierung einfacher Aus- 
kunftssystene. 


Lösungen auf der Basis anderer DBBS (DBS/R, Eigenentwicklungen) 
unter Nutzung des Teilhabersystems ESY/R wurden nach eigenen 
Testergebnissen aus Kapazitätsgründen verworfen, da unser Zen- 
tralrechner vorwiegend für die Forschung und Lehre verfügbar 
sein muß und erst in zweiter Linie für Verwaltungsaufgaben,. 


Als Projektierungsgegenstand wurden arbeitsökonomische Daten 

und Prozesse an einer Hochschule bzw, im Ministeriumsbereich 
ausgewählt, Em erster Komplex wird durch die Stellenplan-Daten 
unserer Hochsdule (MIU) gebildet. Darunter fallen sowohl. die 
Planvorgaben und die Ist-Belegung des Stellenplanes als auch 
Informationen zu den Nitarbeitern der MLU. Dieser Datenfonds 
wurde aus dem vorhandenen Kaderprojekt und dem DBS/R-Stellenplan- 
projekt herausgezogen, 


Ein zweiter Komplex enthält Informationen zım Arhaitakräfta- nnd 
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Lohnfondsplan bzw. -stand aller Hochschulen der DDR geordnet nach 
den Beschäftigtengruppen an den Einrichtungen (z. B. nach Profes- 
soren, Dozenten, Verwaltungspersonal uew.). 

Beide Auskunfts- und Verwaltungssysteme (kurzs AVS) tragen gemein- 
sane Merkmale, die aus den Möglichkeiten und Grenzen des MIMER- 
.Prozedurkonzeptes bzw, der MIMER-QL-Komponente resultieren (andere 
MIMER-Komponenten wurden in die Lösung nicht mit einbezogen): 


- Datenfonds ist als MIMER-Datenbasis gespeichert (siehe Bild 1) 


- Unterstützt werden alle Brozesse der Datenverwaltung und ein- 
fache Standardanfragen 


- Single-user-Systen, d. h. kein Schutz vor konkurrierenden UPDATE 
(dieses läßt sich durch Übergang auf neue MIMER-Versionen bei 
Bedarf umgehen) 


- Nutzung des AVS unter Steuerung des 0S/ES-Teilnehmersystens 
TSO (TSO-Region: 180 K) oder als BTAM-Variante als normaler 
Job im OS/ES (Region: 190 K) 


- MIMER-ProZedurkonzept unterstützt die Menülitechnik 


- Programmiersprache des AVSs MIMER-Prozeduranweisungen und 
MIMER-QL-Anweisungen der Relationensprache, Die so erzeugten 
Programme werden interpretativ abgearbeitet, 


- Problemloser Wechsel von AVS zu MIMER-QL und umgekehrt möglich 


- Ergebnisse der Verarbeitungen sind Zeilen mit Standardüber- 
schriften und Nachrichten (keine Bilder) 


- Kennwortschutz im AVS zu Nutzungsbeginn, Wahl der Verarbeitungs- 
ebene für den geübten und für den ungetibten Nutzer 


- Hilfestellungen teilweise durch einbezogene Dokumentationsteille 
(z. B. Schlüsseltabellen, Codierregeln) 

Unterschiede der beiden AVS: 

Stellenplan-AVS 


- Problemdatenfonds ca. 2 MByte, gegliedert in 5 Problemdaten-. 
tabellen und 2 Sekundärindextabellen 


- geschützte Prozeduren für privilegierte Nutzer 
AK/LOHN=-AVS: 


- Problemdatenfonds ca, 500 KByte, gegliedert in 9 Tabellen 
- Dokumentationsteil als Datenbank-Bestandteil 


Beide AVS arbeiten in vielen Teilen analog. Das 'hier aufgeführ- 
te Beispiel (Bild 2) demonstriert die Arbeitsweise des AVS Ar- 
beitskräfte/Lohnfonds. Es werden jeweils folgende Schritte aus- 
geführt: 


1. Kennwortprüfung 
2. Durchlaufgeschwindigkeitswahl 


3. Wahl der Nutzungsart (Recherche/Verwaltung/Benutzungshilfe- 
etellungen) 


4. Bestimmung der gewünschten Kennziffern und ihrer Ordnungs- 
begriffe 
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PROCDB | nos uns | —-»|1INER — ug 
i MIfER — 
‚Problemdatenb. 


Bild 1 Systemstruktur der AVS 


Eroeffnungsteil 


2 Kennwortpruefung 


Ebene Moduswahl . 
Nutz 
Ebene Recherche/Yers, 
Ordnungs- 
begriffe 
Ebene % 


Kennziffer 


Verarb.— 
ert 


Bild 2 Das AYS Arbeitskraefte/Tohnfonds 
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Abbruch der aktuellen Verarbeitung und Verlassen der jeweiligen 
Verarbeitungsebene "nach oben" ist: möglich, 


Nach erstem Probebetrieb der AVS ist schon nachfolgender Nutzen 
bzw. sind schon nachfolgende Vorteile abzusehen; 


- Schnelle operative Datenverwaltung durch Sofortverarbeitung 
im Dialog; f 


- Einfache Auskünfte sind operativ lösbar; 


- Einfache und gleichsprachige Handhabung im Dialog wie im 
Stapelbetrieb; " 


- Einfache Programmierung der AVS, schneller Entwurf möglich 


- Es ist eine unmittelbare Nutzung der AVS durch den Sachbear- 
beiter möglich; 


- Fehlerbehandlung bei Fehleingaben und Fehlverarbeitung; 


- Keine Konsistenzprobleme, da Änderungen unmittelbar in Daten- 
bestand. 


Als Nachteile haben sich erwiesen; 


- Keine komfortable Verarbeitung im Sinne von Summierungen und 
Prozentberechnungen im AVS. Das liegt vor allem an den zur 
Realisierung verwendeten MIMER-Komponenten bzw. der vorlegen- 
den MIMER-Version. 


- Es sind nur Stendardüberschriften bei Tabellenauswertungen 
möglich; 


- Unemtinschte Systematibchriften sind nur im Komplex unterdrück- 
bar. 


I 


Zusammenfassung 


Mit "MIMER" steht ein DBBS auf relatinnaler Basis zur Verfügung, 
das im Dialog und Stapelbetrieb gleichsprachige Anwendungen er- 
laubt. Die Datenbasis ist einfach erstellbar, schnell verwalt- 
bar und es sind leichte, einfache (oder auch komplizierte) Recher- 
chen möglich. Die Benutzung des DBBS ist leicht erlernbar und 

es ist relativ problemlos in der Handhabung. Der Aufbau und die 
Einführung der beschriebenen AVS zeigen die Nutzerfreundlichkeit 
für den Sachbearbeiter. Es wurde der Nachweis der Funktionsfählg- 
keit des DBBS”Lelativ geringer Ressourcenbelastung erbracht, so 
daß das DBBS "MIMER" für umfangreiche und leistungsfähige Pro- 
jekte anwendbar erscheint. 


Dr. H.-H. Höllering 
K. Schober 


1 


3-16 
Krien, Reinhard: 


Zur Hardwareunterstützung von relationalen Datenbanksystemen 
durch einen Assoziativprozessor 


Die Effektivität eines Datenbanksystems wird wesentlich durch 
den schnellen und flexiblen Zugriff zu der Datenbasis bestimmt. 
Insbesondere erfordert die Verwirklichung des mengenorientier- 
ten Zugriffes in relationalen Datenbanksystemen eine Vielzahl 
von Externspeicherzugriffen, so daß die Antwortzeiten sehr 
schnell anwachsen können und zum Teil nicht mehr akzeptable- 
Werte erreichen. Einen Ausweg aus dieser Situation stellt die 
international stark beachtete Entwicklung dar, Datenbanksysteme 
durch dedizierte Hardware zu unterstützen, bzw. sie in Daten- 
besismaschinen zu integrieren /1/, /2/. Bei. dieser Hardware- 
unterstützung Übernehmen assoziative Speicher- und Verarbei- 
tungseinheiten wesentliche Aufgaben. 

Der Assoziativprozessor AZP K 2064 ist eine Geräteeinheit für 
das Mikrorechnersystem MRS K 1600, der den inheltsorientierten 
Zugriff auf ein Datenvolumen von 1 MByte-gewährleistet /3/. 
Das Arbeitsprinzip des AZP gestattet es, solche Operationen 
der relationalen Algebra wie Selektion, Projektion und Join 
auf Hardwareebene auszuführen. 

Es werden der Aufbau, das Funktionsprinzip sowie die Zusammen- 
erbeit des AZP mit dem Betriebssystem MOOS 1600 dargestellt. 
Anhand eines Auskunftssystems auf der Basis des AZP werden 
einige Effekte diskutiert. i 
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/3/ Krien, R.; Reichard, L.; Zweynert, M.: Assoziativprozessor 
AZP K 2064 zur Unterstützung von Such- und 
Speicheraufgaben im MRS K 1600 
Neue Technik im Büro 28 (1984) 5 S. 148-149 


Dr.-Ing. 'Reinhard Krien, VEB Robotron-Elektronik Dresden, 
Stemmbetrieb, FG Rechentechnik, 8012 Dresden, PSP 330 
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Entwicklungsstand eines VDBS im lokalen Rechnernetz 


1. Einleitung 

In einem solchen komplexen System, wie einem verteilten DBS, 
muß es eine Komponente geben, die eine zentrale Stelle ein- 
nimmt und auf der konzeptuellen Ebene angesiedelt ist. Sie 
koordiniert die Arbeiten aller anderen Komponenten des ver- 
teilten DBS und steuert die Realisierung der allgemeinen Funk- 
tionen der Nachrichtenübermittlung. Es handelt sich dabei um 
die VDBS-Komponente globales Datenbankbetriebssystem, die auf 
jedem Knoten des Rechnernetzes installiert ist. Diese Systen- 
komponente wird im weiteren als Dispatcher bezeichnet. 


2. Struktur des Dispatchers 

Dem Aufgabenspektrum eines verteilten DBS und den damit spe- 

ziell vom Dispatcher umzusetzenden Aufgaben entsprechend, 

wird der Dispatcher modular aufgebaut (s. Bild 1). 

Er setzt sich aus folgenden Moduln zusammen: 

Mi dem Steuermodul DMON, ö 

M2 dem Modul zur Analyse der Nutzeranforderung DSNUTZ, 

M3 dem Modul zur Arbeit mit dem lokalen DBBS DSLDB, 

M4 dem Modul zur Arbeit mit dem nichtlokalen DBBS DSNLDB, 

M5 dem Modul zur Transformation Nutzersicht in die konzep- 
tuelle Sicht DTRSF, 

M6 dem Modul für den Aufbau und die Verwaltung des Katalogs 
DKAT, 

M7 dem Modul für die Verteilung der Anforderungen DVERT, 

M8 dem Modul für den Zugriffsschutz DSICH, 

M9 dem Modul für die Transaktionsanalyse DTRAN, 

M1O dem Modul für die Synchronisation DSYN, 

M11 dem Modul für die Protokollierung DPROT, 

Mi12 dem Modul für Fehlermitteilungen und -behandlung DFEHL, 

M13 dem Modul für Recovery-Maßnahmen DREC. 


Die einzelnen Moduln sind Einheiten, die eine oder mehrere Ein- 
gaben akzeptieren und durch Verarbeitung eine entsprechende 

Ausgabe produzieren. Mit den Moduln Mi bis M13 werden alle Auf- 
gaben, die durch das globale DBBS zu erfüllen sind, bearbeitet. 
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Der modulare Aufbau 168t die Realisierung einer Überlagerungs- 
struktur zu und bietet somit die Möglichkeit einer speicher- 
effektiven Implementierung. Aus Kapazitätsgründen ist es nicht 
möglich, alle Moduln in der Basisversion umzusetzen. Aus die- 
sen Grund werden zunächst nur die zum Funktionsnachweis erfor- 
derlichen Moduln bearbeitet. Die im Bild 1 doppelt gerahmten 
Kästchen bedeuten, daß diese Moduln in der Basisversion imple- 
mentiert werden, alle anderen sukzessive entsprechend der 
Realisierungskonzeption. 


3. Systemkomponente Netzzugriffsprozeß 
Der NZP dient als Interfaceprozeß zwischen dem auf den einzel- 
nen Knoten befindlichen Dispatcher einerseits und dem Komnuni- 
kationssystem andererseits. Der NZP beinhaltet im Sinne des 
0OSI-Referenzmodells die Anwendungsverwaltung und die Exekutive 
zur Kommunikationseinleitung und -durchführung. Entsprechend 
seiner Funktionen ist der NZP auf der Anwendungsschicht 
(Schicht 7) angesiedelt. Mit Hilfe des NZP wird es möglich, 
die für ein verteiltes DBS notwendigen Nachrichten über das 
Kommunikationssystem innerhalb des Netzes zwischen den End- 
systemen auszutauschen. Zur Realisierung dieser Aufgabe be- 
dient sich der NZP der von der Schicht 6 angebotenen Funktio- 
nen. Die Inanspruchnahme der Funktionen erfolgt mit Hilfe von 
Primitiven, in denen Parameter spezifiziert werden. Folgende 
Primitive stehen zur Verfügung: 
- für die Sitzungseröffnung das P_CONNECT vom Typ request/re- 
sponse, i 
- für den Datentransport das P_DATA vom Typ request, 
- für eine Veränderung von Bedingungen das P_PERFORM_NEGOTIA- 
TION vom Typ request/response, 
- für eine vereinbarte Beendigung durch die Teilnehmer das 
P_ RELEASE vom Typ request/response, 
- für einen Abbruch durch den Teilnehmer das P_DISCONNECT 
vom Typ request, 
- für den Abbruch durch den Sitzungsdienst P_ABORT vom Typ 
indication und 
- für die Zusammenarbeit mit der Systemverwaltung das 
P_CONTROL vom Typ request/response. 


7 

P-CON- IND /-CONF P_CoN.-REQ/- RESP 

P.DATA- IND a P_DATA-REA 

P. RELEAS- IND/-CONF P_REL_ REA@/-RESP 

P_DISCON _ IND P-DISCON-REQ 

P_ ABORT- IND P_PERF. NEG_ REA /.RESP 

PR. PERF_NEG. IND/-CoNnF ' 

PCONTROL - IND/-CONF  P-CONTROL _REQR/-RESP 
_——  - -  - iD — — — -— 

Schicht 
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Der NZP muß Datenelemente für die Dienstdateneinheiten (SDU), 

Protokolldsteneinheiten (PDU) und Interfacedateneinheiten (IDU) 

aufbauen, um 

- Anforderungen über das LRN an entfernte Endsysteme senden 
und auswerten zu können, 

- Anforderungen entfernter Endsystene realisieren und ent- 
sprechende Antworten oder Mitteilungen an das anfordernde 
Endsystem übermitteln zu können. 


Zur Erfüllung der Aufgaben der Anwendungsverwaltung muß der 
NZP eine Reihe von Übersichten in Form von Tabellen führen. 
Er führt 

- eine Tabelle für bestehende Verbindungen als Initiator 
(VERBI), 

eine Tabelle fir bestehende Verbindungen als Akzeptor 
(VERBA), 

eine Tabelle für gesendete Anforderungen (GA) und 

eine Tabelle für empfangene Anforderungen (EA). 


Die Tabelle VERBI enthält den Initiatoridentifikator, die Ak- 
zeptorkennzeichnung mit Rechnernummer und Prozeßname des Dis- 
patchars und den Akzeptoridentifikator. 

Die Tabelle VERBA enthält den Akzeptoridentifikator, die Ini- 
tiator-Kennzeichnung mit Rechnernummern und Prozeßname des 
Dispatohers und den Initiatoridentifikator. 

Der Initiator- und Akzeptoridentifikator wird durch die Sit- 
zungsschicht (Schicht 5) vergeben und dient der eindeutigen 
Zuordnung der PIDU'S zu den bestehenden Verbindungen. Der 
Identifikator ist dem Primitiv P_CONNECT_INDICATION und 
P_CONNECT  CONFORMATION zu entnehmen. 

Die Tabelle GA - besteht aus dem Nutzeridentifikator und der 
Kennzeichnung der Senke (je nach Art der Verbindung Akzeptor- 
bzw. Initiatoridentifikator) und die Tabelle EA aus dem Nutzer- 
identifikator und der Kennzeichnung der Quelle (je nach Art 
der Verbindung Initiator bzw. Akzeptoridentifikator). 

Der Nutzeridentifikator dient der eindeutigen Zuordnung der 
Anforderungen, aber auch der Antworten bzw. Mitteilungen zu 
einem Nutzerprozeß und wird durch den Modul DSKUTZ vergeben. 
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Durch den NZP sind folgende Nachrichten und Operationen zu 
realisieren: 
AIDU vom Dispatcher (DSNLDB) 
PIDU vom Netz (Schicht 6) 
Auswerten einer AIDU 
Aufbauen einer AIDU 
Aufbauen einer PIDU 
Auswerten einer PIDU 
Führen der Tabellen 
PIDU an das Netz (Schicht 6) 
AIDU an den Dispatcher (DSNLDB) 


> Bdddad<u il 


4. Das Zusammenwirken der Komponenten im Netz 

Für die Realisierung einer Forderung des Nutzerprozesseg zur 
Arbeit mit den verteilt gespeicherten Daten müssen die betei- 
ligten Komponenten (s. Bild 1) in folgender Art und Weise zu- 
sammen arbeiten. 

Nach dem Start des Dispatchers mıß dieser sich beim Netz an- 
melden. Der Nutzerprozeß übergibt an den Dispatcher (DSNUTZ) 
eine Anforderung. Die Anforderung wird durch den Nutzer- und 
Nachrichtenidentifikator charakterisiert und in die WS einge- 
tragen. Danach wird die Transaktionsanalyse (DTRAN) durchge- 
führt und festgestellt, ob der Nutzerprozeß zugriffsberech- 
tigt ist und wo die Daten sich befinden. Sind die Daten lokal 
gespeichert, dann wird die Transaktion vom Dispatcher (DSLDB) 
an das lokale DBBS Übergeben und die zu erwartende Antwort 
bzw. Mitteilung wird durch den Dispatcher (DSNUTZ) aufgrund 
der geführten Tabellen und bestehenden Identifikatoren an den 
Nutzerprozeß Übergeben. 

Wird festgestellt, daß die Daten nicht lokal gespeichert sind, 
wird die Transaktion durch den Dispatcher (DSNLDB) in Form 
einer A-Interfacedateneinheit an den NZP übergeben. Der NZP 
baut zunächst eine PIDU mit dem P_CON_REQ-Primitiv auf, um 
eine Verbindung mit dem gewünschten Endsystem herzustellen. 
Kommt die Bestätigung des Verbindungsaufbaues (P_CON_CONF- 
Primitiv), so kann der NZP eine PIDU mit dem P_DATA_REQ-Pri- 
mitiv, in dem die Anforderung enthalten ist, an das Netz 
(Schicht 6) Übergebei und somit den Zugriff zu den entfernt 


3-22 
gespeicherten Daten ermöglichen. Als Antwort erhält der NZP 
eine PIDU mit P_DATA_IND, die er auswertet und in Form einer 
AIDU dem Dispatcher (DSNLDB) übergibt. 
In umgekehrter Richtung empfängt der NZP eine PIDU mit P_CON_ 
IND, womit mit ihm eine Verbindung gefordert wird. Als Antwort 
sendet er eine PIDU mit P_CON_RESP mit dem Einverständnis oder 
Ablehnung an den initiierenden Knoten, Bei Einverständnis wird 
er eine PIDU mit P_DATA_IND mit der entsprechenden Forderung 
zum Zugriff zu den Daten auf seinem Knoten empfangen. Diese 
Anforderung. wird an den Dispatcher (DSNLDB) in einer AIDU 
übergeben und von ihm (DSLDB) an das LDBBS weitergegeben. Die 
Antwort bzw. Mitteilung geht den entgegengesetzten Weg an den 
NZP und von diesem in einer PIDU mit P_DATA_REQ an den ini- 
tiilerenden Knoten zurück. 
Wird bei der Verbindungsaufnahme in der Antwort im P_CON_CONF 
im Diagnoseparameter mitgeteilt, daß der. gewlinschte Prozeß 
(Dispatcher) nicht aktiv (nicht bekannt) ist, so wird vom NZP 
durch Aufbau und Absenden einer PIDU mit P_CONTROL_REQ an die 
Systemverwaltung, diese aufgefordert, den Prozeß auf dem ge- 
wünschten Endsystem zu starten. Erhält der NZP durch eine 
PIDU mit P_CONTROL_CONF eine positive Antwort, kann er erneut 
ein P_CON_REQ zur Verbindungsaufnahme absenden. 
Soll die Verbindung abgebaut werden, so wird eine PIDU mit. 
P_REL_REQ abgesetzt und die Bestätigung durch P_REL_CONF ab- 
gewartet, bevor die Verbindung aus den Tabellen ausgetragen 
wird. Nachdem alle Verbindungen abgebaut sind und der Dis- 
patcher seine Arbeit beenden will, muß er sich vom Netz ab- 
melden. Es kann während der Arbeit auch ein Verbindungs- 
abbruch durch P_DISCON_IND oder P_ABORT_IND auftreten. 


Die Konvertierung aufgrund des heterogenen Netzes erfolgt in 
der Schicht 6. Zu diesem Zweck werden im P_CON_REQ bestimmte 
Parameter spezifiziert. Ergeben sich während des Bestehens 
der Verbindung Änderungen, so können diese mit dem P_PERFORM_ 
NEGOTIATION_REQ mitgeteilt werden. 


Damit die NZP auf den einzelnen Knoten sich verstehen, was 
mit den ankommenden Nachrichten zu tun ist, werden A-Proto- 
kolle ausgetauscht, die z. Z. nur den Nutzer- und Nachrich- 
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tenidentifikator enthalten. Die Nachrichtenlänge und der 
Initiator- und Akzeptoridentifikator können der P-Interfaoer- 
steuerinformation (PICI), die die ersten 9 Byte der PIDU b»- 
legt, entnommen werden. 


Autor: 


Dipl.-Ing. Mollenhauer, Erhard \ 


Ingenieurhochschule Dresden 
Sektion Informationsverarbeitung 
8019 Dresden 

Hans-Grundig-Str. 25 
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Recovery für Datenbasen, die im Dialog aktualisiert werden 


Die z.Zt gebräuchlichen Systeme zur Aktualisierung gro- 
Ber Datenbasen enthalten meist nur epärliche Vorkehrungen 
für den Fehlerfall. Moderne Methoden zur Manipulation von 
Datenbasen (z.B. Dialogsysteme) kommen ohne Maßnahmen zur 
Fehlerbehandlung nicht aus, 


Ausgehend von einem-Fehlermodell werden im Vortrag die 
einzelnen Recovery-Fälle für eine Datenbasis aufgezeigt 
und behandelt, 


Wie mit Hilfe der Auflösung von Datenmanipulationen in 
Transaktionen und der Bereitstellung entsprechender Tools 
Recovery realisiert werden kann, wird am Beispiel des Systems 
 BASTARD gezeigt. 


Bernd Pälecke 
Karl-"arx-Univereität Leipzig, ORZ 
701 Leipzig 

Karl-Marx-Platz 
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Entwerfen der Grobstruktur der Datenbasis zur Leitung 
‘einer Wirtschaftseinheit 


Für ein Industriekombinat und seine Betriebe ist zu konzipie- 
ren, wie die Arbeitsteilung bei der maschinellen Datenverar- 
beitung zur Unterstützung der Leitung langfristig gestaltet 
werden soll. Das verlangt unter anderem, die Struktur der 
Datenbasis im Zusammenhang mit der Projektgliederung und der 
Aufteilung der technischen Mittel zu entwerfen, 


Eine Datenbasis für die Leitung stellt ein Modell des Lei- 
tungsobjekts und seiner Beziehungen zur Umgebung dar, wie es 
für das Lösen der Leitungsaufgaben relevant ist. Sie reprä- 
sentiert wesentliche Eigenschaften einzelner Objekte durch 
Datensätze, -felder und -gruppen. Klassen differenziert aggre- 
gierter Objekte und deren Beziehungen werden durch Satzmengen 
und Satzmengenrelationen widergespiegelt. Die Gesamtheit der 
Beziehungen zwischen Satzmengen einer Datenbasis soll als. 
Grobstruktur der Datenbasis bezeichnet werden. Durch einzelne 
Leitungsaufgaben sind externe Datenbasen und durch die Gesant- 
heit berlicksichtigter Aufgaben die konzeptionelle Datenbasis 
“begründet. Die interne Datenbasis verdeutlicht eine Datenstruk- 
tur, die ablauf- und speicherorganisatorischen Anforderungen 
entspricht. 


In der Literatur wird vorgeschlagen, die Datenbasis nach Prädi- 
katen durch horizontale und vertikale Partitionierung von Da- 
tenrelationen aufzuteilen. Dabei entstehen entweder Teilmengen 
für Objekte, die hinsichtlich ihrer Abbildungserfordernisse 
einer gemeinsamen Grundgesamtheit angehören, oder Teilmengen 
für Objekte mit unterschiedlichen Attributen beziehungsweise 
für differenzierte Attribute zu Objekten. Das satzweise Auf- 
teilen nach einem eindeutigen Schlüssel oder nach Zugriffs- 
statistiken wird als wenig praktikabel bewertet. 
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Bekannte Methoden und Verfahren für das Entwerfen der Struktur 
“ einer Datenbasis gehen 


- von einer semantischen Analyse der Beziehungen zwischen 
Attributen aus, die zum Bestimmen von Satzmengen führt, 
oder 

- von der Synthese der Satzmengen und ihrer Beziehungen 

i eus, an die sich Attributszuweisungen zu Satzmengen an- 
schließen. 


Das Ergebnis der semantischen Analyse der Beziehungen zwischen 
Attributen anhand der Attributsnamen ist jedoch nur insofern 
variabel, wie unterschiedlich benannte Schlüsselattribute ver 
schiedene Objektklassen vertreten. Daher führen sie in der Re- 
gel zum Bilden von Satzmengen für Objektklassen, zwischen denen 
keine oder solche Beziehungen bestehen, daß Attribute von Objek- 
ten verschiedener Klassen auch als ein: Satz eines aggregierten 
Objekts angesehen werden können. Verschiedene Satzmengen für Ob- 
jJekte, die hinsichtlich der abzubildenden Attribute einer gemein- 
samen Grundgesamtheit angehören, ergeben sich daraus nicht. 


Solche Satzmengen existieren aber vielfach für die Leitung einer 
Wirtschaftseinheit. Sie resultieren daraus, daß zwischen den ab- 
gebildeten Prozessen in der Wirtschaftseinheit hierarische Be- 
ziehungen bestehen und in verschiedenen Prozessen Objekte einer 
gemeinsamen Grundgesamtheit enthalten sind. Beispiele sind Da- 
teien für "Arbeitsgegenstände eines Betriebes", "Arbeitsgegen- 
stände eines Produktionsbereiches" oder "Arbeitsgegenstände ei- 
nes Produktionsabschnitts" beziehungsweise Dateien für "Kenn- 
ziffern sämtlicher Kostenstellen" oder "Kennziffern der Kosten- 
stellen der Vorfertigung".. Aufgrund der Arbeitsteilung zwi- 
schen den Leitungsorganen, unterscheiden sich externe Datenbasen 
zu Leitungsaufgaben, die auf unterschiedliche Prozesse, aber 
partiell auf dieselben Objekte bezogen sind, oft erheblich 

durch die Attribute. Das begrlindet die Nützlichkeit, nach Pro- 
zessen differenzierte Satzmengen flir ähnliche Objekte sichtbar 
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zu machen, und ist bei der Synthese der Modelle (Schemata) der 
konzeptionellen und der internen Datenbasis zu berlicksichti- 
gen. 2 
Dies kann durch eine Synthese erfolgen, die von benannten Satz- 
mengen ausgeht. Sie kenn sich auf Entity-Relationship-Methoden 
stützen. Aus der Literatur sind allerdings ausreichende Hinweise 
nicht bekannt, wie mit Hilfe eines geeigneten Modells der konzep- 
tionellen Datenbasis eine Struktur einer verteilten internen Da- 
tenbasis entworfen werden kann, die einen hohen Nutzeffekt der Da- 
tenverarbeitung gewährleistet. Nachfolgend wird ein Ablauf des 
Entwerfeng vorgestellt, wie es zum Ermitteln der Grobstruktur 
der Datenbasis für die Leitung der Produktionsdurchführung in 
einen Kombinat der metallverarbeitenden Industrie exerxiert wurde. 


Der Ablauf der Synthese von Modellen zu Datenbasen ist durch die 
vorgesehene Verwendung der Modelle determiniert. Das Modell der 
konzeptionellen Datenbasis sollte als Grundlage für die Synthese 
des Modells der internen Datenbasis dienen und zugleich die Ana- 
lyse des Niveaus der Datenverarbeitung, der Gemeinsamkeiten und 
Unterschiede des Leitungsobjekts und der Leitungsaufgaben zu an- 
deren Wirtschaftseinheiten, zuklinftiger Strukturen des Leitungs- 
objekts, der Verträglichkeit der Anwendungsbedingungen vorgefer- 
tigter Datenverarbeitungslösungen mit vorliegenden Voraussetzungen 
sowie die Synthese von Leitungsaufgaben und ihre Zuordnung zu 
Leitungsstruktureinheiten unterstützen. 

Diesen Aufgaben wird das Modell nur gerecht, wenn es die für die 
Leitung relevanten Prozesse und Klassen der ProZeßelemente sowie 
die Beziehungen zwischen den Klassen sichtbar macht, Dies ist 
durch ein Vorgehen zu erreichen, das im Unterschied zu anderen 
Methoden auch Satzmengen zu verschiedenen Klassen von Objekten 
einer Grundgesamtheit mit den Relationen zwischen ihnen ausweist. 
Es verläuft in den Schritten 5 


- Aufstellen der Modelle externer Datenbasen, 

- Zusammenfügen dieser Modelle und 

- Prüfen und Erweitern der Vollständigkeit des 

. Modells hinsichtlich zu berücksichtigender 
Leitungsaufgaben. 
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Voraussetzung dafür ist, daß beim Aufstellen der Modelle ex- 
terner Datenbasen bereits Satzmengen bestimmt und exakt de- 
finiert werden. Folgt das Entwerfen der Datenbasis der Dekon- 
position der Datenverarbeitungsaufgaben für die Leitung nach 
dem Top-down-Prinzip wird zuerst die vorläufige Grobstruktur 
einer externen Datenbasis sowie danach ihre Fein- und endgül- 
tige Grobstruktur bestimmt. Die Grobstruktur entsteht dadurch, 
daß die Leitungsaufgabe durch Satzmengen für zugeordnete Ob- 
jektklassen und deren Beziehungen beschrieben wird. In der Li- 
teratur heißen diese Modelle auch "lokale" oder "funktionelle 
Entity-Modelle", 
Vielen Projektanten fällt es leichter, mit der Zusammenstel- 
‚lung der Attribute einer externen Datenbasis zu beginnen und 
sie danach in Satzmengen zu ordnen. Das Ermitteln der Feinstruk- 
tur schließt das Prüfen der Attribute auf Zerlegbarkeit ein. 
Für jedes Attribut ist festzustellen, ob es einer der bereits 
definierten Objektklassen direkt zugeordnet werden kann oder 
ob es ein primäres Attribut einer anderen Klasse aggregierter 
Objekte darstellt. i 
Beim .Zusammenfligen der Modelle externer Datenbasen zum Modell 
der konzeptionellen Datenbasis wird zu jeder Objektklasse, die 
für Leitungsaufgaben relevant ist, eine Satzmenge definiert. 
Beziehungen zwischen Satzmengen werden entsprechend den Objekt- 
beziehungen deklariert. Ein Modell der konzeptionellen Daten- 
basis entsteht durch das 


- Prüfen der in den externen Modellen enthaltenen Bezeich- 
‘nungen für Satzmengen und Attribute auf Homonymität und 
Synonynität, 

- Beseitigen homonymer und synomymer Bezeichnungen, 

- Übertragen der unterschiedlichen Bezeichnungen für Satz- 
mengen, die den Objektklassenbezug sichtbar machen, aus 
den Modellen der externen Datenbasen, 

- Zusammenfassen der in den Modellen zu einer Satzmenge 
enthaltenen Bezeichnungen für Attribute und Übertragen 
der unterschiedlichen Bezeichnungen zu jeder Satzmenge, 
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- Ableiten und Übertragen einer Bezeichnung flir die Be- 
ziehung zwischen zwei Satzmengen, zwischen denen in 
den Modellen der externen Datenbasis übereinstimmende 
oder unterschiedliche Beziehungen gekennzeichnet sind 
sowie durch das 

= Kennzeichnen der Beziehungen zwischen Satzmengen, die 
els Mengen einer gemeinsamen. Grundgesamtheit anzusehen 
sind. 


Die Aussagekraft des Modells für verschiedene Analysen erhöht 
sich mit zunehmender Vollständigkeit hinsichtlich der gegenwäm 
tig und zuklinftig zu lösenden Leitungsaufgaben. Damit wird zu- 
gleich dem nachträglichen Änderungsaufwand für die Datenbasis- 
struktur entgegengenirkt, da die Mehrzahl der Änderungen aus 
unvollkommenen Ergebnissen eines Bottom-up-Vorgehens oder aus 
der Entwicklung des Leitungsobjekts und der Leitungsorganisation 
herrühren. Das durch Zusammenfügen vorliegender Modelle externer 
Datenbasen entstandene Modell der konzeptionellen Datenbasis 
wird daher aufgrund von Vergleichen mit analogen Modellen ande- 
rer Wirtschaftseinheiten, mit Modellen aus der Literatur, mit 
anderen Modellen des Leitungsobjekts und mit Modellen zur- Ent- 
wicklung des Leitungsobjekts vervollkommnet. Die Vervollkommnung 
ist mit Entscheidungen Über die Vorgabe von Leitungsaufgaben 
verknüpft. 

Es ist eine interne Datenbasis anzustreben, die eine hohe Reak- 
tionsfähigkeit der Leitungsorgane bei geringen Aufwand ermög- 
licht. Eine solche Datenbasis kann durch Nachnutzen effektiver 
Lösungen oder durch Variantenvergleich gefunden werden. 

Modelle interner Datenbasen werden vorwiegend in Verbindung 

mit Programmlösungen nachgenutzt. Die Übernalme eines Modells 
setzt voraus, daß der Nutzeffekt der enstprechenden Datenbasis 
nachgewiesen wurde, es sich auf ähnliche leitungsorganisatori=- 
sche Voraussetzungen bezieht und seine Umsetzung praktikabel 
ist. 

Anderenfalls wird das Aufstellen und Vergleichen von Varianten 
unumgänglich. Varianten der internen Datenbasis ergeben sich 
grundsätzlich dadurch, daß im Modell der konzeptionellen Daten- 
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basis enthaltene Festlegungen libernommen oder das Auftreten 
bestimmter Daten, von Daten, die aus anderen ableitbar sind, 
und von Relationen sowie die Zuordnung von Satzmengen zu Ob- 
jektklassen gegenüber der konzeptionellen Datenbasis geändert 
wird. Der Syntheseaufwand läßt sich einschränken, wenn vor- 
rangig solche Varianten aufgestellt werden, deren Auswahl 
überdurchschnittlich wahrscheinlich ist. Dem wird mit einer 
Satzmengendefinition entsprochen, die neben der Übernahme vor 
alem auf der Elimination von Satzmengen des Modells der konzep- 
tionellen Datenbasis beruht, die nachfolgend klassifiziert 
wird. 


Arten der Elimination von Satzmengen . 


- die vollständig redundante Teilmengen einer anderen Satz- 
menge darstellen, 


- die zu Satzmengen vollständig redundant sind, die Teil- 
mengen der Objekte einer Grundgesamtheit enthalten, 


- deren Daten vollständig durch die Verknüpfung von Daten 
zu anderen Objekten ableitbar sind, 


- die einen Teil der Objekte vollständig redundeant zu an- 
a eneen abbilden, wobei Satzmengen für disjunkte 
ekte 


. abgetrennt oder 
. nicht abgetrennt werden, 


- die sämtliche Objekte teilweise redundant zu anderen Satz- 
mengen abbilden, wobei Satzmengen für disjunkte Attribute 


. abgetrennt oder 
“. nicht abgetrennt werden, 


- die Teilmengen zu disjunkten Objekten einer Grundgesant- 
"heit darstellen beziehungsweise 


- deren Daten Satzmengen zu aggregierten Objekten desselben 
Prozesses zugeordnet werden. 


Beispiele sind Fertigungsauftragsdateien für einen Produktions- 
bereich und für diesen untergeordnete Abteilungen, die diffe- 

renziert redundant sein können. Die Daten der Dateien "Arbeits- 
gänge" und "Arbeitsorte" können auch der Datei "Fertigungsauf- 
träge" zugeordnet sein. Diese Variationen werden durch das Hin- 
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zufligen von Satzmengen für ausgewählte Attribute zu Objekten 
und durch Elimination von Relationen zwischen Satznengen er 
gänzt, die: im Modell der konzeptionellen Datenbasis enthalten 
sind. 
Um die Anzahl aufzustellender und zu bewertender alternativer 
Varianten und damit den Entwurfsaufwand gering zu halten, folgt 
die Auswahl der Aufstellung von Varianten in einer Reihenfolge, 
bei der durch Eliminationsentscheidungen, die Anzahl nachfolgen- 
der Entscheidungen eingeschränkt wird. 


Variantendefinition und -auswahl 


Beginn ‚ 
Viederhole für alle Variationsarten 
Wiederhole für alle vertikalen Leitungsbeziehungen 


Wiederhole für alle horizontalen Leitungsbeziehungen 


Bestimme Satzmengen, die eliminiert oder hinzuge- 
fügt werden können! A 


Bilde Varianten der Elimination von Satzmengen und 
Relationen sowie des Hinzufügens von Satzmengen! 
Ordne die alternativen Varianten in einer Rangfolge 


nach fallendem Nutzeffekt! 
zur Grobstruktur des Modells der 
aD alecbanfer - | 


Ende 
Alternative Varianten zum Übertragen von Satzmengenaus dem Modell 


der konzeptionellen Datenbasis ergeben sich durch ihre Elimination 
mit oder ohne Hinzufügen anderer Satzmengen beziehungsweise durch 
Elimination anderer Satzmengen derselben Grundgesantheit mit 

oder ohne Hinzufligen weiterer Satzmengen. Varianten, die in einen 
Vergleich als weniger effektiv eingestuft wurden, sollten bei 
nachfolgenden Variantendefinitionen vernachlässigt werden. 

Es werden nur solche Abwelahungen vom Modell der konzeptionellen 
Datenbasis bestätigt, die zur Gewährleistung nachfolgend aufge- 
führter zeitlicher, räumlicher und anderer Erfordernisse der 
Aufgabenlösung oder aus personellen, technischen beziehungsweise 
ökonomischen Gründen erforderlich werden oder die nachweisbare 
Aufwandssenkungen bewirken. 
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‚Aggtriichionen für die Variantenaufstellung und auswahl, 


Erfordernisse der Leitungsaufgaben: 


AUESDEOHDAERLESHO Anzahl aus einer Satzmenge benötigter 
tze 
rimäre und sekundäre Sortierung der auszugebenden Sätze 
äufigkeit des Lösen einer Leitungsaufgabe je Zeiteinheit. 
zeitliche Verteilung der Aufgabenlösung je Zeiteinheit 
A zulässige Reaktionszeit beim Lösen der Leitungs- 
aufgabe 
geforderte Aktualität zu verarbeitender Daten 
Zuordnung von Leitungsaufgaben zu Leitungsorganen 
Geheimhaltung von Daten 
räumliche Verteilung der maschinellen Verarbeitung und 
Datenausgabe an die Leitungsstruktureinheiten 


vem&ibare technische Mittel: 


Art und Anzahl der Geräte 
Konfiguration 

Betriebssysteme 
Datenträgerarten oder -anzahl 


Leistungsfähigkeit und Kostensätze der technischen Mittel: 


Operations-, Verarbeitungs- oder E/A=-Geschwindigkeiten 
Zugriffe- und Reaktionszeiten 

'Speilcherkapazitäten 

Fehlerrate und Verfügbarkeit 

Kostensätze je Betriebszeiteinheit 


Konventionen verwendeter Betriebssysteme: 


zulässige Anzahl an Relationen, in denen eine Satzmenge 
enthalten sein kann 

zulässige Anzahl von Hierarchiestufen 

zulässige Anzahl an Datei- oder Segmenttypen 

zulässige Anzahl an Elementen in Dateien oder 
Segmenten 


personenbezogene Voraussetzungen: 


vorhandene Zeitfonds- und UOTE N ODER N der 
Arbeitskräfte 

Bedien- und Wartungsaufwand 

Bedien- und EEE LE 
Qualifikationsanforderungen 

Forderungen bezliglich der Arbeitsbedingungen 
Arbeitskräftelimit 


ökonomische Vorgaben: 


Kostenlimit 
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Die Satzmengen der internen Datenbasis werden zusammen mit den 
Zugriffspfaden und den Datenflüssen festgelegt, was Entscheidungen 
über die Abgrenzung der längerfristig als Stammdaten zu speichem- 
den Satzmengen, der aus diesen Satzmengen durch Verarbeitung ab» 
geleiteten und temporär als Arbeitsdateien zu gestaltenden Satz- 
mengen sowie der Satzmengen für die Datenerfassung einschließt. 
Dem entspricht, Varianten der Datenbasisstruktur mit Prozeßablauf- 
modellen zu verknüpfen. Veränderte Modelle der Grohstruktur der 
Datenbasis bedingen stets neue ProzeBabläufe. Einem Strukturmo- 
dell können jedoch verschiedene Prozeßablaufmodelle zugeordnet 
werden. Vor allem in Abhängigkeit von der Anzahl sowie von der 
zeitlichen und räumlichen Verteilung der Prozesse für die Speiche- 
_ rung und Auswertung, von den Zugriffs- und Verarbeitungszeiten 
"sowie von den Kostensätzen je Zeiteinheit verändert sich. der Nutz=- 
effekt einer bestimmten Datenbasisstruktur. Daher bezieht sich 
der Vorzug einer bestimmten Variante Begenüber einer anderen 
auf unterstellte Prozeßabläufe. 
Für die Auswahl einer Variante sind in vielen Fällen Aussagen 
über erwartete Aufwände entscheidend, Voraussetzung dafür ist, 
daß die alternativen Varianten annähernd gleiche Bedingungen 
für die Reaktionsfähigkeit der Leltungsorgane schaffen. Auswir- 
kungen von Varianten lassen sich oft auf die 


- Anzahl und Kompliziertheit der Arbeitsgänge und Pro- 
gremnme, 

Zeiten für Datenein- und-ausgaben zu einem Arbeitsgang, 
Zeiten für Datenein- und=ausgaben über alle Arbeitsgänge 
je Zeiteinheit, 

Speicherplatzbedarfsstruktur und auf die 

Kosten beim Datenträgereinsatz 


feststellen. Eine Elimination von Satzmengen des Modells der 
konzeptionellen Datenbasis ist vorzuschlagen, wenn infolge ver 
ringerter Datenredundanz erzielbare Einsparungen an Speicherungs- 
aufwand höher zu werten sind als unter Umständen infolge anwach- 
sender Ballastanteile oder steigender Anzahl auszuwertender Satz=- 
mengen auftretende zusätzliche Auswertungsaufwände, sofern die 
Ausprägung anderer Nutzeffektsmerkmale nicht untersucht wird. 
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Das Hinzuflgen von Satzmengen gegenüber dem Modell der konzep- 
tionellen Datenbasis ist gerechtfertigt, wenn’sich dadurch 
der Auswertungsaufwand stärker verringern läßt, als der mr 
cherungsaufwand gleichzeitig steigt. 
Redundanzarme Datenbasen besitzen in der Einheit mit einer zen- 
tralisierten maschinellen Datenverarbeitung Überwiegend mehr 
Vorteile als in Verbindung mit Formen verteilter Verarbeitung. 
Demgegenüber wirkt eine teilweise oder eine vollständig ve 
teilte Verarbeitung vielfach mit Datenbasen vorteilhaft zusan- 
men, in denen mehrere Satzmengen zu Objekten einer Grundgesanmt- 
heit vorliegen. Daher liefern die Klassen von Elementen der 
für die Leitungsorgane relevanten Prozesse wesentliche Prädika- 
te für Entscheidungen Über die räumliche Verteilung der Speiche- 
rung und Verarbeitung von Daten. _ 
Als Entscheidungshilfe dienen Datenbasisdiagramme, die Relatio- 
tionen zwischen Satzmengen für Objekte eines Prozesses und zwi=- 
schen Satzmengen für Objekte mehrerer Prozesse sichtbar machen. 
Ein Datenwörterbuch, das gegenwärtige und zuklinftige Strukturen 
des Leitungsobjekts sowie ihren Zusammenhang zu Leitungsaufge- 
ben und -organen verdeutlicht, stellt ein weiteres Werkzeug dar. 

Für die Leitung der Produktionsdurchführung im untersuchten 
Industriekombinat entstehen Modelle der konzeptionellen und der 
internen Datenbasis mit Satzmengen, die nach vier Leitungsebenen 
getrennt sind. Das Modell der internen Datenbasis weist einige 
Satzmengen aus, beispielsweise zu Arbeitsgegenständen, Arbeits- 
plänen, Stücklisten, Arbeitsorten, Arbeitskräften oder Grundmit- 
teln, die durch mehrere Leitungsorgane auszuwerten sind. Andere 
Satzmengen, zum Beispiel für Fertigungsaufträge, Zeitfonds, 
Kosten oder Plankennziffern, werden vorwiegend durch einzelne 
Leitungsorgane genutzt. Es bietet sich an, diese Datenbasis in 
Form einer teilweise zentralisierten und teilweise räumlich 
verteilten Verarbeitung zu verwenden. 


Dr. Kurt Porkert 
Friedrich-Schiller-Universität 
Sektion Wirtschaftswissenschaften 


6900 Jena 
Schillerstr. 8 
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Prescher, Gerold 


Datenbankentwurf mit dem Entity- Relationship- Modell 


1, Einleitung 


Die Effektivität von Datenbanken ist heute vor allem die Effek- 
tivität ihres Entwurfes. Am Problem des Datenbankentwurfes wird 
weltweit gearbeitet (siehe 2. B. / 1 //2//3!) 

Das relationale Datenmodell und die Theorie der funktionalen 
Abhängigkeiten (Functional Dependency, Abkürzung: FD) und der 
mehrdeutigen Abhängigkeiten (Multivalued Dependency, Abkürzung; 
MVD) werden im Datenbankentwurf angewendet, 

Bisherige Ansätze für den Datenbankentwurf (z.B. /1//4/) 
setzen voraus, daß eine Menge funktionaler und/oder mehrdeuti- 
ger Abhängigkeiten zur Verfügung steht. Arbeitsgegenstand des 
Entwurfsprozesses ist dann die Manipulation der Abhängigkeiten 
mit dem Ziel des Aufbaus einer Relationenstruktur, die der 
Codäschen Normalformenlehre gehorcht. Geht man davon aus, daß ' 
der Aufbau einer Datenbank in seiner ersten Phase die nichtpro- 
zedurale Darstellung eines erhobenen Ausschnittes der objekti- 
ven Realität unter ständiger Beachtung des Zweckes der Daten- 
bank ist, so ergibt sich, daß der Datenbankentwurf nicht allein 
Aufgabe des Informatikers sein kann. Der Entwurf der Datenbank 
muß vielmehr aus dem Sachgebiet heraus erfolgen, dessen Bearbeli- 
ter auch den Zweck der Datenbank formuliert. 

In dieser Phase der Modellierung kann schwerlich schon die Ab- 
leitung der vom Informatiker benötigten Abhängigkeiten durch 
den Bearbeiter des Sachgebietes erwartet werden. Es geht hier- 
bei um die erste Erhebung von Interessenobjekten und des zwi- 
schen ihnen bestehenden Geflechtes von Beziehungen. Unterschät- 
zung der Bedeutung dieser Phase, fehlende Hilfsmittel und man- 
gelhafte Zusammenarbeit Sachgebietsspezialist - EDV- Fachmann 
haben z. T. zu einem Anwendungsstau auf dem Gebiet der Daten- 
banktechnologie bzw. zu uneffektiven Datenbankentwürfen ge- 
führt. Deshalb sind beim Datenbankentwurf Modelle heranzuziehen, 
die die Formalisierung der erhobenen zweckrelevanten Semantik 
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des Sachgebietes mit dem Ziel der Gewinnung der Datenbankstruk- 
tur unterstützen. Das Entity- Relationship- Modell / 5 / (im 
folgenden wird dafür auch die Abkürzung ERM verwendet) wurde 
euf seine diesbezügliche Eignung untersucht (s. a. / 6./) 


2. Das Entity- Relationship- Modell als Darstellungsmittel 


Das ERM eignet sich für die Etappe der Fixierung von Modellvor- 
stellungen in einem Sachgebiet (Erhebungsphase). In seiner Dar- 
stellungskraft und semantischen Reichhaltigkeit wurde es bereits 
vielseitig erprobt (siehe z. B. / 7 /). Das Entity- Relation- 
ship- Modell beruht auf der Darstellung von Objekten (Entities) 
und der zwischen ihnen bestehenden Beziehungen (Relationships), 
die als 1 : 1, 1 : N und M : N- Beziehungen typisiert sind, 
Zwischen je zwei der als Rechtecke. dargestellten Entities 

(s. a. Abb. 1) kann mehr als eine Relationship (durch Rhomben 
gekennzeichnet) bestehen; in diesem Fall spricht man von Rollen, 
Entities und Relationships werden benannt und können Attribute 
(durch Kreise versinnbildlicht) besitzen. In Abb. 1 wurden aus 
Übersichtlichkeitsgründen keine Attribute aufgenommen. 

Vorzüge des ERM sind Übersichtlichkeit und Klarheit der seman- 
tischen Darstellungsmöglichkeiten. Der sachliche Hintergrund in 
Abb. 1 ist das vereinfachte Modell einer Abteilungsorganisation. 


2 besteht 


gehört 


Abb. 1: Beispiel für ein Entity- Relationship- Modell 
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Das Entity- Relationship- Modell wirkt als logisch zwinzgendes 
Instrument bei der Formulierung von Objekten und Zusammenhän- 
gen, die beim Erfassen von Ausschnitten der objektiven Reali- 
tät erkannt werden. Das Modell dient im Verein mit Begriffs- 
katalogen der entwurfsbegleitenden Dokumentation, die z. T. 
schon rechnergestützt mit Graphik- Unterstützung erarbeitet 
wird / 8 /. Das als Entwurfsergebnis vorliegende ERM erlaubt 
jedoch noch nicht ohne weiteres die Ableitung der äquivalenten 
Menge von Abhängigkeiten oder gar von Relationen, die in Codd- 
scher Normalform sind. Selbst wenn die Beschreibungen der Ge- 
genstände als Relationen in zweiter oder sogar vierter Normal- 
form vorgegeben und eingehalten werden, können sich immer noch 
über die dargestellten Beziehungen Verletzungen der Normalfor- 
men bei der Ableitung der Beziehungsrelationen ergeben. 
So ist z. B. die Beziehung Person - Abteilung in Abb. 1 tran- 
sitiv. 
In der Literatur / 3 / wird dem ERM vorgeworfen,daß es nicht 
Basis für die Entwicklung automatisierter Entwurfsverfahren 
sein könne. Vom Verfasser durchgeführte Untersuchungen / 6 / 
ergaben, daß das ERM sehr wohl Ausgangspunkt für den Ansatz 
von Algorithmen sein kann, welche die Beziehungsmenge in eine 
Menge von Abhängigkeiten zerlegen. Diese Abhängigkeiten werden 
unter Einwirkung der von Armstrong / 9 / aufgestellten und von 
Beeri, Fagin und Howard / 10 / weiterentwickelten Axiomatik so 
manipuliert, daß sie Grundlage für eine Datenstruktur sein kön- 
nen, die hohe Datenunabhängigkeit, Redundanzarmut und Beherr- 
schung des Update garantiert. Eine solche Datenstruktur kann 
als Bestandteil der konzeptuellen Ebene im Sinne der bekannten 
ARSI/SPARC- Architektur aufgefaßt werden. 


3. Transformation des Entity- Relationship- Modells in einen 
Graphen 


Ein graphentheoretischer Ansatz für die Darstellung und Behand- 
lung funktionaler Abhängigkeiten wurde u. a. von Rogge und Tön- 
jes / 4 / verwendet. Neuere theoretische Untersüchungen zur Ma- 
nipulation funktionaler Abhängigkeiten durch Graphenalgorithmen 
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liegen von Ausiello, D'Atri und Sacca / 11 / vor. 
In diesen Ansätzen werden vorhandene Mengen funktionaler Ab- 
bängigkeiten bestimmten Ordnungsprinzipien unterworfen (Norma- 
lisierung). Bei einer Übertragung des ERM in ein Graphennodell 
steht aber zunächst einmal die Ableitung von Abhängigkeiten aus 
der Semantik des dargestellten Modells im Vordergrund. Da die 
funktionale Abhängigkeit ein Spezialfall der mehrdeutigen Ab- 
hängigkeit ist, muß im Interesse der Verallgemeinerung und bes- 
serer Modellierbarkeit ein Transformationsansatz gefunden wer- 
den, der die Ableitung mehrdeutiger Abhängigkeiten gestattet. 
Das Auftreten mehrdeutiger Abhängigkeiten ist mit der vierten 
Bormalform gekoppelt und kann für den Faginschen Dekompositi- 
onsansatz / 1 / ausgenutzt werden, 
Abb, 2 zeigt den durch Transformation des ERM nach Abb. 1 er- 
seugten Graphen, Alle Abhängigkeiten sind in ihrer allgemeinen 
Form. als mehrdeutige Abhängigkeiten durch Doppelpfeile darge- 
stellt, 


Abb. 2; Durch Transformation erzeugter Graph des Beispiels 
aus Abb. 1 


Bei der Transformation müssen die unterschiedlichen Beziehungs- 
typen und evtl. vorhandene Beziehungsattribute berücksichtigt 
werden. In Abb, 2 wird der Ersatz der M ; N- Beziehungen des 
ERM durch je einen hin- und rückwärtsgerichteten Doppelpfeil 
deutlich. ö 
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4. Auswertung des transformierten Graphen - 


Der aus dem ERM transformierte Graph wird als Darstellungsmo- 
dell der entworfenen Datenstruktur (Entwurfsschema) einer Be- 
handlung unterzogen, deren Ziel die Herstellung eines verbes- 
serten Schemas ist. Dazu wird der Graph den im folgenden be- 
schriebenen Schritten unterworfen, 


Schritt 1: 4 


, 


Ermittlung der stark zusammenhängenden Knoten des transforuier-| 
ten Graphen. Die so gewonnenen stark zusammenhängenden Teil- | 
graphen (zyklische Teilgraphen) geben die Mengen aller durch 

M : N- Beziehungen miteinander verbundenen Entities an, 

Sie sind durch beziehungsdarstellende "Allschlüssel"- Relati- 
onen beschreibbar. 


Schritt 2: 

\ ß 
Bildung eines Graphen ohne zyklische Knotenverbindungen (azyk- 
lischer Graph) durch Umwandlung der starken Teilgraphen in 
Knotenpunkte des azyklischen Graphen, 


Schritt 3: 


Erzeugung der nichtredundanten minimalen Überdeckung durch Ent- 
fernen redundanter transitiver Kanten im azyklischen Graph. 


Schritt 4: 


Zerlegen der aus den zyklischen Teilgraphen entstandenen Knoten 
des azyklischen Graphen durch Ermittlung der Knoten des zykli- 
schen Teilgraphen, die zu (nichttrivialen) mehrdeutigen Abhän- 
gigkeiten in der durch den Teilgraphen repräsentierten Rela-- 

tion zusammentreten. Für die Erleichterung dieser Prüfung sind 
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die redundanten Kanten des starken Teilgraphen zu entfernen, 
Bezogen auf den in Abb, ‚2 dargestellten transformierten Graph 
ergibt die Prüfung auf das Enthaltensein zyklischer Teilgraphen 
gemäß Schritt 1 den durch die Enotenmenge mit den Elementen "GR", 
"PROJ" und "RAUM" gebildeten starken Teilgraphen TG 


7G = {GR, PROJ, Raum}. 


Schritt 2 dient der Bildung eines azyklischen Graphen, der den 
Teilgraph TG als einen Knoten aufnimmt (s. Abb. 3). 


® 


/ 
GREPROMRAUM | (u) 


Abb. 3: Azyklischer Graph Abb. 4: Resultierender Graph 


Gemäß Schritt 3 werden redundante transitive Abhängigkeiten 
entfernt (gestrichene Verbindung PERS - ABT in Abb. 3). 
Dieser Schritt ist identisch mit der Herstellung der nichtre- 
dundanten minimalen Überdeckung der Abhängigkeiten, die eine 
starke Verwendschaft zur dritten Normalform aufweist (s. a. 
ı12nD. . 

Der in Abb. 3 dargestellte Knoten GR # PROJ # RAUM symbolisiert 
eine Beziehungsrelatioön 


RB (GR, PROJ, RAUM) 


Da sich die Spaltenwerte "RAUM" in dieser Relation für alle 
Spaltenwerte "PROJ" wiederholen (die "GR" zugeordneten Werte 
"RAUM" sind unabhängig von "PROJ") wird in RB eine mehrdeutige 
"Abhängigkeit 


GR —>» RAUM 


gehalten. Damit ist RB nicht in vierter Normalform. Auf Basis 
des Faginschen Dekompositionsansatzes ist eine Zerlegung in 
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zwei Relationen RB1 und RB2 möglich: 


RB (GR, PROJ, RAUM) 


RB1 (GR, RAUM) RB2 (GR, PROJ) 


In den resultierenden Graph (s. Abb. 4) sind die in vierter 
Normalform bestehenden Relationen RB1 und RB2 als mehrdeutige 
Abhängigkeiten eingebracht, Die Knoten dieses Graphen sind En- 
tityrelationen (Gegenstandsrelationen), seine Kanten stellen 
Beziehungsrelationen dar. Die Gegenstandsrelationen repräsentie- 
ren dabei funktionale Abhängigkeiten eines jeden Attributes zum 
Schlüsselattribut und sind damit wie die Beziehungsrelationen 
in vierter Normalform,. _ 

- Das in den Abb. 1 bis 4 dargestellte Demonstrationsbeispiel ist 
sehr einfach gewählt. Die Schritte 1 bis 4 können hier ohne 
weiteres manuell abgearbeitet werden, Bei komplexeren ERM ist 
dies jedoch nicht so einfach möglich. Für solche Fälle müssen 
Algorithmen bereitgestellt werden, 


5. Algorithmen für die Auswertung transformierter Graphen 


Der aus dem ERM transformierte Graph wird zweckmäßigerweise 

durch graphentheoretische Algorithmen ausgewertet. Für die 

Realisierung dieser Algorithmen lassen sich vielfach allgemein 

bekannte Softwarekomponenten verwenden. 

Es wurden im einzelnen entwickelt (ses. a. / 6 /): 

- Algorithmus zum Existenznachweis starker Teilgraphen in ei- 
nem Graphen 


- Algorithmus zur Bestimmung der Knotenmengen starker Teilgra- 
phen auf der Basis von an der Hauptdiagonalen verdichteten 
Binärmatrizen 


- Algorithmus zur Entfernung überflüssiger Kanten in zyklischen 
Graphen auf Grundlage der Rückführung der Aufgabe auf das 
Traveling- Salesman- Problem unter der Berücksichtigung 
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Hamiltonscher Kreise (Anwendung des Programmpaketes 
DISKO / 13 /). 


- Entfernung Üüberflüssiger Kanten in azyklischen Graphen auf 
der Basis mehrfacher Matrizenmultiplikation 


- Prüfung auf das Helten angesetzter mehrdeutiger Abhängigkei- 
ten in Relationen. 

Mit Hilfe der angeführten Algorithmen ist eine Rechnerunter- 

stützung für das Umsetzen umfangreicher und in ERM- Form dar- 

gestellter Modelle möglich. Sie stellen eine Ergänzung der 


rechnergestützten Hilfsmittel für den Datenbankentwurf dar, wie 
sie etwa mit Begriffskatalogen oder Data Dictionary- Systemen 
zur Verfügung stehen. 


6. Zusammenfassung 


Das Entity- Relationship- Modell ist ein semantisch reichhal- 
tiges Modell, das eine klare Darstellung der Objekte eines: 
Sachgebietes und der zwischen ihnen bestehenden Beziehungen zu 
geben vermag. Das dargestellte:Modell ist erweiterungsfähig. 
Auf Grund der genannten Eigenschaften ist das ERM für den Da- 
tenbankentwurf aus dem Sachgebiet heraus gut geeignet. 

Die Transformation des ERM in einen Graphen und dessen analy- 
tische Behandlung erleichtern eine rechnergestützte Übernahme 
der Vorstellungen des Entwerfers (Sachgebietsspezialisten) 

durch den EDV- Fachmann in der Form abgeleiteter Abhängigkeiten. 
Für die Analyse des transformierten Graphen wurden Algorithmen 
entwickelt, die weitgehend auf allgemein eingeführter Software 
beruhen. Die Algorithmen liefern eine Struktur von Relationen in 
vierter Normalform für das betrachtete System. 

Die entwickelten Algorithmen stellen somit eine Ergänzung der 
Anwendung des Entity- Relationship- Modells im Sinne der Über- 
führung von Modellvorstellungen in logische Datenbankstrukturen 
der. 


10 
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ON TESTING OF A DISTRIBUTED DATABASE MANAGEMENT SYSTEM 


Abstract 


A method has been developed for testing of a process con- 


trol 


database management system. The database is distributed 


on various mini- and microcomputers interconnected by ä high- 
speed communication network. The aim of the testing was 


This 


1.1. 


to check functional correctness of the system, 

to set up an installation test system, 

to measure the most important characteristics of the 
systen. 


paper describes the applied methods and software tools. 


1. Introduction 


The PCDB (Process Control Database Management System) 
[3] allows users to perform various operations on a dis- 
tributed database, where the data are distributed amongst 
local bases stored on mini- and microcomputers inter- 
connected by a high-speed communication network. The 
minis are TPA 11 computers supervised by the operating 
system RSX 4.0, the micros are INTEL 8080 based intelli- 
gent (CAMAC) crate controllers (ICC-s) supervised by the 
minis. 

The components of the PCDB are. executed by the TPA 11 
minicomputers except the program handling the data resi- 
ding on the ICC-s. 

The PCDB makes use of the relational data model. Data 
can be stored in three places: in the memory or on the 
disks of a minicomputer or in the memory of a microcom- 
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puter. 

There are three types of relations: relative, special and 
indexed relations. Relations residing in the core can have one 
o£ the following two types: relative or special. Relations 
stored on disks can be indexed in addition. One relation can 
be resident only on one medium at a time. 

Thre are four types of relation manipulation routines [5]. 
The first group consists or routines reserving and releasing 
relations. The record manipulation routines operating on the 
rows of a relation form the second group. The third group of the 
routines operates on the fields (attributes and bittributes) of. 
a relation and the fourth one operates on the columns of a 
relation. The routines of the second and the fourth group can 
be =xecuted in synchronous or asynchronous way. 

5 The schema describing tne relations can be stored in the 
memory or on the disk of the local minicomputer controlling the 
corresponding data. In th& schema one relation is represented 
by one record. The schema description retrieval routines give 
informations about the relations or about the fields of a 
relation. 


The test system of the PCDB has been designed in cooperation 
with the constructors of the PCDB on the basis of the PCDB 
user’s manuals. ® 


Our task was to create a test system complying with the 
following principal requirements: 


- checks the functional correctness of the services 
supported by the PCDB for users, 

- maintains the measuring of the most important charac- 
teristics of the system, 


- can be used as the test system of. a new installation. 


Applying Hetzel’s terminology [1] our aim was to set upa 
test system supporting the so-called certification and perfor- 
mance procedures. = 


} 
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The further part of the paper discusses briefly the 
general principles of the test method (section 2). In the 
third section there are presented the software tools used 
during the working up of the test system. The important 
characteristics are discussed as well. The fourth section 
gives a summary of our experiences. 


2. General pricinples 


The test system consists of two main parts, one of them 
are the programs and the other is the database. 


Our requirements concerning the database were as follows: 


the database should contain at least one relation of 
all kinds on storages of the possible types, 

the internal structure of the relations should make 
it possible to test the normal working of the PCDB 
and to check the error messages, 

the database should support the examination of the 
synchronization and effectiveness of the distributed 
system, 

the same database should be loadable on each mini- 
computer of the network, 

the loading of the data sets of the database should 
be recovered easily after a system crash. 


The programs form more subsystems according to the rela- 


tion 


mänipulation routines: 


open-close subsystem to test the reservation and re- 
lease of the relations, . 
record manipulation subsystem to test the record 
management routines, 

field manipulation subsystem to test field operations, 
column manipulation subsystem to test column operations, 
schema description subsystem to test schema description 
retrieval operations. 
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There is a further subsystem, the so-called performance 
analysing subsystem to measure the most important features 
of the PCDB. Each subsystem consists of one or more 

programs written on the programming language Fortran. IV. 

The programs are connected with each other by command files 
to form a subsysten. The subsystems can be executed in- 
dependently, but can be arranged as a single test system 

by means of command files. Several copies of the test system 
can be executed with different parameters on the different 


minicomputers of the network at the same time. 


3. Applied tools 


3.1. Software_tools \ 


Several utility programs are attached to the PCDB 
system to support the construction, loading and modi- 
fication of relations [4]. 


For example, 


a) the schema processor generates the following output 
files 


-, the internal format of the schema, 

- source listing with error messages, 

- RMS indexed file definitions, 

- FCS random äccess file definitions for relative 
relations; 


b) relation editor (RDT) is an interactive utility 
program for loading, modifying and testing the fields 
of the records; 


c) relation copy program (RCP) is a utility for copying 
a sequential file in character form into a relation 
and inversely. The sequential file can be generated 
and modified by any text editor. 


3.2. 


* 
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The operating system and the PCDB system itself have a 
number of services to query the states of the running 
programs and the relations used by them. 


One of the most important services of the .PCDB is the 
Monitor. The state of the database can be examined by 
the Monitor at optional intervals. For example, the mode 
of reservations, the user of the relation can be inspec- 
ted. Informations can be asked about the free space of 
the spooler, about the contents of the tables of the PCDB. 


The test database 


The test database has been constructed according to the 
principles mentioned above. The database consists of 
about 50 relations, 42 relations of them have been 
divided into 6 relation-groups. This is done to simplify 
the loading of the database. 


The groups have been composed from the relations having 
the same record structure apart from the "keyed" 
attribute. 


As a relation can have relative, special or indexed 
organization and can be stored on the disks or in the 
core of the computers (except indexed relations wich can 
be stored on the disks only), seven relations belong to 
a group. n 


The relations can be specified for the schema processor 
as follows: 


RELATION RDSPDP 
(RSON : INT2, KEYED: 1, 2; 
KEY1 : STR, KEYED : 3, 6; 
KEY2 : STR, KEYED : 9, 2; 
VFL4 : FLT4 VECTOR: 11, 40) 
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ALLOCATION: 15 RECORDS; 

SPECIAL; 

SCHEMA: DISK;. DATA: DISK; 

DATA FILE: ’AB = C215, 2161 RDSPDP.SPC’ 


The relation above declares a relation of special type. 
Each relation has a key named RSQN (record sequence number). 
In addition it has a key-field of string type and a key- 
field of integer type. Data-fields are floating-point 
numbers forming a vector of 10 elements. The relation can 
have 15 records at most. ‘The schema describing the relation 
and the relation itself are stored on the disk. The rela- 
tion is saved in the standard DOS-RV file named RDSPDP.SPC. 


The relation residing in the core and belonging to the 
same group as the relation above can be declared as 
follows: 


RELATION RDRECP 
(RSQN: INT2, KEYED: 1, 2; 
KEY1: STR : 3, 6; 
KEY2: INT2 ı 9, 2; 
VFL4: FLT4 VECTOR: 11, 40) 
ALLOCATION: 15 RECORDS; 
RELATIVE; 
SCHEMA: DISK; DATA: CORE; 
DATA FILE: ’AB = (215, 216] RDRECP.COR’ 


Specifying the relation-groups in the way outlined above, 
it is sufficient to create a single copy of the source 
files for each group, and the relations can be loaded from 
them by means of the utility RCP. 

The structure and the content of the relations have been 
fixed according to the services tested by the group of the 
relations. 


3.3. 
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The test database can be loaded on several minis of 
the network at the same time, moreover while testing the 
distributed system the database must be loaded on all of 
the minis. 


The programs have been arranged into subsystems accor- 
ding to the operations on the relations. An optional sys- 
tem of programs can be formed from the subsystems by 
command files. Several copies of the systems can be 
executed on the minis at the same time. Parameters can 
be passed to the systems by different DOS-RV files. The 
files of the parameters can be created by command files. 


The parameters can be given in the following way: 


- residence type: ALL, DISK, CORE or ICC. 

It defines the storage containing the relations to 
be tested; 

- mode of execution: ALL, SYNCHRÖNOUS or ASYNCHRONOUS. 
It defines the version of the record management 
routines to be tested; 

- number of processors: a number of integer type. 

It defines the number of minicomputers to be tested. 

- processor identifier 1: identifier of a minicomputer; 


= processor identifier n: as above. 


The test programs begin their works according to the 


"parameters with the database on the local computer. The 


same activity will be executed on each given minicomputer 
of the network after each other. 

To save the consistency of the database, the test 
programs modifying the relations must recover the database. 
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This feature of the programs makes it possible to exe- 
cute several copies of the test system at the same time 
and to use the database without loading again supposing 
there is no other reason (for example system crash). 


4. Experiences 


The test system has been constructed on the basis of 
the user’s documentations. The error messages of the 
PCDB proved to be incomplete. Seven new messages have 
been created. We directed attention of the constructors 
to the incompletness and the ambiguity of the documenta- 
tions (about 10 instances). 


Using the schema processor five errors have been 
discovered, each of them can be led to the carelessness 
of the constructors.' 


For example, there were given no error messages when 
bittributes were defined to the vector attributes, or 
host attributes were declared as keyed variables (both 
are prohibited). 


About 25 errors were detected during the testing of 


‚ the record management routines. Three of them can be led 


to planning problems, the others proved to be errors of 
the coding. Several errors were due to the poor logical 
checking of the field and column operations. The source 
of three errors turned out to be the faulty sinchroniza- 
tion of the distributed system. 
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The performance analysing subsystem has been created 
to measure the most important features of the distributed 
‚system. The subsystem makes it possible to measure the 
average execution time of certain operations on different 
relations both in the local and in the distributed system 
under given software and hardware circumstances. 


The complete performance analysis of the system will 
be made in the future, but there are already a number 
of remarkable conclusions. 


For example, the searching time should be incependent 
of the place of the records in the case of relations of 
special type residing in the core. Whereas it was found, 
that the searching time increased highly in the case 
of local relations by the growth of the RSQON. On the 
other hand, in the case of remote relations the time 
increased in a substantially smaller degree. Obviously 
the searching algorithm must be improved in the local 
case. 
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CAUKAPHUH MK. 
ÄBTOHATISHPOBOHHAN CHCTEeHA YIPAanxeHun OCKOBcKmı yHNDepcHTeTrCH 


B ee06cHNH PACCMATPHBADTCH O0MIS HPKHUKII OPTAHRSAIIH H diyHR- 
INOHHPOBAHHN ABTCHATHINPORAHHON CHCTEMM yıpazueumm MOCKOBCKOFO yEH- 
sopeXTeTa, HCNOXSYeNoN Nix B6ecmeusHnn yusöHe-HayıHof, AMIIHHCTBA- 
2EBHofi HM deiNANcoBo-XosnicrseHnHeli HontexsHoctn MY. NMaercn ommcanne 
APXNTOKTYPH CHCTEIN, ASMKOB OÖMEHHR TIonpsonarexeii C ACY, Iporpamnı- 
HIIt. CPEACTD OPTAHNZAININ H DEHOHHN 603 HAHHIX. ÜCoÖco BHMIAHIe YIe- 
ANOTCH HPOÖXENE- YHHÄIKOUHH IIPOCKTIEIL M TEXHONETHUECKNX PpemeHmii IIPH 
COSAAHAH ÄyHEIMOHRXBHUX rIexcncrem ACY HIV. 
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Spezifikation von Software zur Verwaltung von Datenbasen 
1. Einführung 


Ein wichtiger Gegenstand der Softwaretechnologie ist die Beschäfti- 
gung mit der Entwicklung von Softwaresystemen, die zur Automatisie- 
rung und Rationalisierung komplexer informationeller Prozesse ge- 
schaffen werden. Kennzeichen solcher Softwaresysteme ist eine un- 
fangreiche, meist komplex strukturierte, permanent. zu speichernde 
Datenbasis. Der "Stand der Kunst" ist dabei u.a. gekennzeichnet 
durch geeignete Modularisierungsprinzipien, die sich auf das 
PARNAS'sche "information hiding" zurückführen lassen. Eine direkte 
Anwendung solcher Prinzipien ist die Betrachtung der Datenbasis 
und der auf ihr erlaubten Operationen als abstrakter Desentyp?) bzw. 
Datenkapsel /TRAU 84/. 

Im weiteren soll davon ausgegangen werden, daß das zu entwickelnde 
Softwaresystem so entworfen ist, daß Datenbasismanipulationen auf 
einem von physischen Details unabhängigen Niveau beschrieben sind. 
Ein entsprechendes sprachliches Mittel zur Erreichung dieses Ziels 
ist die Entwurfssprache PADEL /LITK 84/. Dann können die in der 
Implementierungsphase anstehenden Aufgaben wie folgt kurz umrissen 
werden: 


- Überführen des Entwurfsergebnisses in die Notation der Implemen- 
tierungssprache, 
- Implementieren der Datesbasis und der Datenbasissoftware. 


Die zweite Aufgabe steht im Mittelpunkt der weiteren Ausführungen. 

Die Implementation der Datenbasis soll die folgenden Aktivitäten 

umfassen: 

- Treffen von Implementierungsentscheidungen über die physische 
Repräsentation der Objekte der Datenbasis /TRAU 82a, TRAU 82b/, 

- Anlegen der Datenbasis, 

- Laden der Datenbasis. 
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Mt "Datenbasis-Software" wird zunächst die programmtechnische 
Realisierung der Operationen auf den Objekten der Datenbasis be- 
zeichnet. Es wird noch sichtbar, daß dies nur ein minimaler Kern 
der Datenbasissoftware ist. Sie zu implementieren ist nicht trivials. 
Bei modellhafter Betrachtungsweise läuft daher im Softwareentwick- 
lungsprozeß (Prozeßprodukt: Softwaresystem zur Automatisierung in- 
£formationeller Prozesse) ein weiterer Softwareentwicklungsprozeß 
(Prozeßprodukt: Datenbasissoftware) ab. 


[3 


pezifizieren 


 Implementieren 


Impiemen- | implementieren 
tieren DB ıDB-Software 


Spezifizieren 


bierungs sprache 


Abb, 1 \ 
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Wichtig ist die folgende Forderung: Im Ergebnis des Spezifierens 
entsteht eine Spezifikation. Ihr Inhalt muß hinsichtlich Vollstän- 
digkeit und Genauigkeit so beschaffen sein, daß die zu entwickelnds 
Datenbasis-Software alle notwendigen Funktionen bei Einhaltung er- 
forderlicher Leistungsparanmeter erfüllt. 


2 Inhaltliche Anforderungen an die Spezifikation von Datenbasis- 
Software 


Bezüglich des Leistungsvermögens von Datenbank-Software muß eine 
Orientierung an modernen Datenbankbetriebssystemen (DEMS) erfolgen, 
denn diese sind nichts anderes als universell nutzbare Datenbasis- 
Software. Daraus folgt, daß die inhaltlichen Anforderungen an die 
Spezifikation von Datenbasis-Software aus den folgenden Fählgkel- 
ten abzuleiten sind: 


(1) Hauptaufgabe jeder Datenbasis-Software muß es selbstverständ- 
lich sein, den Zugriff zu den Daten der Datenbasis -zu gewähr- 
leisten. Dazu ist die Abbildung der Objekte auf logischer Ebene 
in physische Objekte zu handhaben, 


(2) Da möglicherweise nicht jeder Nutzer zu allen Daten zugreifen 
darf bzw. unterschiedliche Manipulationen für unterschiedliche 
Nutzer erlaubt sind, muß die Zugriffskontrolle an Hand bestimn- 
ter Autorisierungsrechte ausgeübt werden. 


(3) Punkt (2) spricht bereits die Existenz mehrerer Nutzer an. Im 
allgemeinen Fall arbeiten einige davon im konkurrierenden Modus, 
so daß auf der Basis geeigneter Sperreinheiten oin Sperrmecha- 
nismus zu realisieren ist.. 


(4) Obne hier die verschiedenartigsten Definitionen der Integrität 
diskutieren zu wollen, steht doch fest, daß im weitesten Sinne 
Maßnahnen für die Wahrung der Integrität der Datenbasis zu 
realisieren sind. 


(5) Die Datenbasis-Software hat Recovery-Maßnahmen zu gewährleisten. 
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(6) Wie ein roter Faden zieht sich durch alle bisher genannten 
Fähigkeiten bzw. Aufgaben: die Forderung nach Effizienz. Um 
Effizienz an der einen oder anderen Stelle zu erreichen, führen 
deshalb moderne, leistungsfähige DEMS bestimmte Optimierungen 
durch, 


(7) Eng im Zusammenhang zu den Optimierungen, aber auch als Basis 
für Tuningmaßnabmen, stehen Messungen bzw. Sammlung statistisch 
euswertbarer Informationen. 


(8) Zunehmend wird Bedeutung erlangen, daß einzelne Funktionen der 
Datenbasis-Software durch Hardwarekomponenten realisiert werden 
können» 


3. Zur Exaktheit der Spezifikation 

Es ist viel diskutiert worden zu Pro und Contra von Formalisierun- 

gen auf der Ebene der Spezifikation, z.B. /KREO 81/. Folgende Über- 
legungen sind bei einer Einordnung zwischen die beiden Extremwerte 

"natürlich-sprachlich" und "formal" im hier vorliegenden Fall anzu- 
stellen: 


- Eine Rechnerunterstützung beim Treffen vom Implementierungsent- 
scheidungen /TRAU B2a, TRAU 82b/ kann dazu benutzt werden, Teile 
der Spezifikation (Punkt (1) im Abschn. 2 betreffend) maschinell 
zu erzeugen. 

= Eine exakte Spezifikationssprache bietet darüber hinaus potentiell 
die Möglichkeit der maschinellen Weiterverarbeitung, was einer 
Rechnerunterstützung der nachfolgenden Phasen des Softwareent- 
wicklungsprozesses entspricht. 


Um diesen Anforderungen gerecht zu werden, wurde eine Spezifika- 
tionssprache (ISL) konzipiert, die sowohl maschinell verarbeitbar 
als auch durch hohe Problemtransparenz und deskriptives Niveau gut 
vom Softwareentwickler handhabbar sein soll, 

Entsprechend der in Abschn. 2 aufgelisteten inhaltlichen Anforde- 
rungen sind zugehörige ISL-Sprachteile konzipiert, wobei diese Aus- 
sage nicht bedeutet, daß es sich dabei um selbständige, separier- 
bare Teile handelt. 
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m on md 


Abb. 2 


Neben der Zuordnung der inhaltlichen Anforderungen zu Sprachteilen 
soll Abbildung 2 die grundsätzliche - weil alles tangierende - Be- 
deutung von ISI-MAP und ISL-OPT zeigen. 
Die konkretesten Vorstellungen existieren gegenwärtig bezüglich 
ISL-MAP (s. unten), die anderen Teile sind ganz grob "angedacht". 
ISI=HARD stellt einen "weißen Fleck" dar. 

\ 


4. Einige ausgewählte Bestandteile von ISL-MAP 


Entsprechend der Aufgabe von ISL-MAP, nämlich die Zuordnung von 

logischen Datenbasis-Objekten und deren Manipulation zu physisch 
existierenden Objekten und deren Manipulation zu gewährleisten, 

muß ISL-MAP die folgenden Bestandteile enthalten: 
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(1) Abbildungsbeschreibung 

(2) Beschreibung der logischen Datenbasis-Objekte (TUPELSET) 

(3) Beschreibung der physischen Datenbasis-Objekte (TABLE, LINKTABLE) 
(4) Beschreibung der Attribut-Typen der Datenbasisobjekte. 


Einige Bemerkungen zu (2): 


EHRE Abbildungs- E -verarbeit- 


beschreibung bare Struktur 


logische Struktur . 
TUPELSET . Strukturname 


Auf der physischen Ebene gibt es zwei Objekttypen, das TABLE und 

das LINKTABLE, das sich nur hinsichtlich seiner Aufgabe vom TABLE 
unterscheidet. Mit ihm soll angezeigt werden, daß eine Verbindung 
zwischen ‚TABLEs existiert. Diese Information kann in Abhängigkeit: 
von den verfügbaren Speicherstrukturen für die Implementation ausge- 
nutzt werden. Die weiteren Angaben im nachfolgenden Syntaxdiagramm 
sind abhängig von der Abbildungsbeschreibung, die unten noch vorge- 
stellt wird. 


.1 DRiS-verarbeit- 
bare Struktur . . 
Table-Typ Table-Name | 


Table-Name 


Table-Spezifikation 


Table-Typ 24 


went 
LINKTABLE 
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Für die syntaktische Notation der Abbildungsbeschreibung sind zu- 
nächst mögliche respektive sinnvolle Abbildungen zu betrachten. Die 
einfachste Form ist eine 1:1-Abbildung in dem Sinne, daß ein logi- 
sches Objekt (TUPELSET) auch ein physisches Objekt (TABLE oder LINK- 
TABLE) wird. Dafür wurde der Operator TRANSFORMED geschaffen. Eine 
weitere Möglichkeit besteht darin, das logische Objekt aufzuteilen 
durch eine horizontale Dekomposition (Operator DECOMPOSED) oder 
durch eine vertikale Dekomposition (Operator: SEGMENTED). In beiden 
Fällen entstehen mehrere physische Objekte (durch AND aneinanderge- 
reiht), und in der 'Table-Spezifikation'! wird beschrieben, was dlese 
Objekte voneinander unterscheidet. 

Für das vollständige oder teilweise Zusammenfügen von logischen Ob- 
jekten zu einem physischen wurde der Operator PARTIALLY CLUSTERED 
eingeführt. 


Es ergibt sich; - 


Abbildungs- 2 
beschreibung . 
2) —_r0) 


PARTIALLY 
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Ein kurzes Beispiel illustriert die bisher eingeführten Konstruk- 
tionen. 


Beispiel: 

ZUPELSET material IS ITRANSFORMED IO TABLE material 
TUPELSET disp IS TRANSFORMED TO TABLE disp 
TUPELSET matdisp IS CLUSTERED TO TABLE material 
TUPELSET matlag IS TRANSFORMED TO LINKTABLE matlag 


Für die detailliertere Beschreibung der Datenbasis-Objekte 
((2) und (3)) ist weitgehend übereinstimmend konzipiert: 


Attribut-Beschreibung 


DEFINED 


Hinzu kommt beim LINKTABLE die Beschreibung des Links (der Verbin- 
dung). Innerhalb der Attributbeschreibung ist im wesentlichen zu 
spezifizieren, ob es sich um ein Primärschlüsselattribut, ein Link- 
attribut, ein Sekundärschlüsselattribut handelt. 


5 Äquivalenzen zum Datenbankentwurfsprozeß und Schlußfolgerungen 


In Abschnitt 1 erfolgte die Einoränung der Datenbasis-Software-Ent- 
wicklung in einen übergeordneten Softwareentwicklungsprozeß. Dies 
war nützlich für die Herausarbeitung der Spezifikationsschnittstelle. 
Betrachten wir nun den Datenbanklebenszyklus und fragen, ob es dort 
Verwendung für die (oder eine ähnlich) konzipierte sprachliche 
Schnittstelle gibt. 


Nach der Phase des Entwerfens im Softwareentwicklungsprozeß ist der 
Beschreibungszustand der Datenbasis vergleichbar mit dem konzeptu- 
ellen Schema einer Datenbank (entspr. ANSI/SPARC-3-Ebenen-Konzept). 
In der Implementierungsphase des SEP ist dann eine Abbildung auf 
die physischen Gegebenheiten einer Basismaschine zu realisieren, 
was vergleichbar mit der Aufgabe des Datenbankadministratore (DBA) 
ist, das konzeptuelle Schema in ein internes Schema zu transformie- 
ren. 


Zwei Dinge sind an dieser Stelle bemerkenswert: 


(1) Voraussetzung dafür, daß der DBA hierbei vor einer anspruchs- 
vollen Aufgabe steht, ist eine gewisse Leistungsfähilgkeit des 
zu nutzenden DBMS, d.b., daß der DBA überhaupt Entscheidungs- 
möglichkeiten zur Auswahl physischer Realisierungen besitzt. 


(2) Während auf konzeptueller und externer Ebene sprachliche Mittel 
zur Verfügung stehen, gibt es auch international keine Möglich- 
keit der exakten Beschreibung des internen Schemas und seiner 
Beziehung zum konzeptuellen Schema. (Eine Ausnahme bildet der 
CODASYL-orientierte Ansatz, beschrieben in /TOZE 7B/). 


Dabei wäre eine solche exakte sprachliche Schnittstelle mehrfach 
bedeutsam: 


(1) Sie wäre das Instrument des DBA zur Definition des internen 
Schenmas. 

(2) Sie könnte für den DBA Instrument und Bezugspunkt für Tuning- 
maßnahmen sein. 

(3) Sie könnte Dokumentationszwecken im Datenbankentwürfsprozeß 
dienen. 

(4) Beschreibungen auf dieser sprachlichen Ebene wären abspeicher- 
bar und maschinell interpretierbar, so daß eine Basis für die 
durch das DBMS zu realisierende Abbildung ("schema mapping") 
vom konzeptuellen in das interne Schema gegeben wäre. j 


6. Konzeptionelle Überlegungen für die Rechnerunterstützung des 
Datenbankentwurfsprozesses 


Die nachfolgende Abbildung 3 soll zunächst graphisch die Konsequenz 
der bisherigen Überlegungen veranschaulichen. Die geschwärzten Ver- 


bindungen dokumentieren, daß das DBMS für seine Arbeit auf jeden 
Fall Informationen über das konzeptuelle und Jas Interne Schema 
sowie deren Zusammenhang braucht. Die Frage ist nur, 

. wie umfangreich diese Informationen sind, 

. wie sie verfügbar gemacht werden können, 

. wofür sie noch genutzt werden können. 


SEIN 
Schema | 


internes F 
Schema 


Datenbası 
ber die )2 ) Meta-Datenbasis 


Abb. 3 


ext.Sch. = Elenes Schema ‚AP= Anwendungsprogramm r 
A = Nutzer bzw. Mutzergruppe 
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Über die Arbeit des DBMS hinaus könnte damit eine Meta-Datenbasis 
für den DBA zur Verfügung stehen. Dies drängt den Gedanken an ein 
Data Dictionary (DD) auf, dessen Aufgabe ganz allgemein darin be- 
steht, Daten über Daten abzuspeichern, 

Der internationale Trend zeigt eindeutig /MELL B4/: 


(1) die zunehmonde Bedeutung (integrierter) Data Dictionaries 

und 

(2) den Wandel von ihrer ursprünglich ausschließlich deskriptiven 
Funktion zu einer zunehmend steuernden, den Nutzer (hier: DBA) 
bei seiner Arbeit führenden Funktion. 


Das DD, mit entsprechenden Fähigkeiten ausgestattet, kann zunm'"Werk- 
zeugkasten des DBA" werden. Mit zunehmenden Integratlionsgrad und 
Erweiterung der Anwendbarkeit auch auf frühe Phasen des Datenbank- 
lebenszyklus (z.B. logischer Datenbankentwurf) führt dann die Ent- 
wicklung analog zum Softwareentwicklungsprozeß zu einem Database 
Engineering Environment (DEE bzw. DE® ; vgl. SEE bzm sE® /EESS 81/). 


Es gibt bereits Veröffentlichungen /ORR-84/, die - ohne explizite 
Bezugnahme auf den Datenbanklebenszyklus - noch einen Schritt weiter- 
gehen und als Nachfolger die CAD/CAP-Systeme (Computer Aided Design/ 
Computer Aided Programming) für die nächsten Jahre voraussagen.« 
Deren wesentlichen Merkmale sollen sein: 


e Überstreichen eines weiten Wirkungsbereiches. (Planungsphase, 
Spezifizierungsphase, Entwurf und Implementierung, Datenbasisent- 
wurf, Wartung usw.) 

e.dle an diesen Prozessen Beteiligten haben direkten Zugriff zu 
ihren Datenbasen, um Systeme, Programme, Datenbasen, Dokumsnte 
usw. zu manipulieren und zu entwickeln. 


Für den "Werkzeugkasten" sind zunächst folgende Inhalte denkbar: 

(1) Informationsdienste 
Unterschiedliche Informationen (Relationen der DB, Attribute der 
Relationen, Wertebereiche der Attribute, angelegt (Datum), letz- 
tes’ Hinzufügen, existierende Sekundärzugriffspfade usw.) sind 
in unterschiedlichen Formen (Reports, Diagramme, grafische Über- 
sichten usw.) ableitbar. 
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(2) Werkzeug(e) für den physischen DB-Entwurf 
Das Instrumentarium, das hier in Betracht kommt, wird zunächst 
durch die beim physischen DB-Entwurf anstehenden Entscheidungen 
beeinflußt /TRAU 83/. 
Vorrangig wären zu nennen: 
- Auswahl von Speicherstrukturen 
- Auswahl von Sekundärschlüsseln 
- Auswahl von Realisierungsvarianten für die Zugriffspfade an 
° Hand von Sekundärschlüsseln 
- Auswahl von Speicherzuoränungsstrukturen. 
Dieses Spektrum ist DEMS-abhängig, sowohl hinsichtlich des Un- 
£angs als auch hinsichtlich der einzelnen Entscheidungsräune. 
Unabhängig von der konkret anstehenden Entscheidung, läßt sich 
Rechnerunterstützung typischerweise wie folgt erreichen: 
- Generierung von Varianten 
- Bewertung von Varianten 
und eventuell a 
- Auswahl einer optimalen Variante bzw. Unterstützung bei der 

Auswahl einer optimalen bzw. "guten" Variante. 


(3) Werkzeug(e) für den logischen Datenbankentwurf (bis zur Formu- 
lierung des konzeptuellen Schemas) 


(4) Werkzeug(e) zur Sammlung und Analyse von Anforderungen an die 
DB im Verlaufe der Nutzungsphase. 
Die Sammlung von Informationen über die Nutzung der DB und ihre 
perspektivische Entwicklung ist von großer Bedeutung für den 
DB-Entwurfsprozeß, unabhängig davon, ob dieser rechnerunter- 

’ stützt abläuft oder nicht. Die Führung des Entwerfers sowie die 

Einbeziehung von Nutzern sind durch die angesprochenen Werkzeuge 
anzustreben. 


(5) Tuning-Möglichkeiten für den DBA 
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Waldmann, Lutz 


KDS2000 - ein datenbankähnliches Datenverwaltungsseystem für 
Mikrorechner K1600 


1. Einführung 


KDS2000 dient zur Verwaltung kleiner bis mittlerer Datenmengen 
auf Mikrorechner K1600. Es kann in verteilten Systemen zur tem- 
porären Verwaltung von Auszügen großer Datenbestände, die auf 
zentralen ESER-Rechnern geführt werden, oder zur eigenständigen 
Vernaltung von Daten eingesetzt werden. Mit KDS2000 ist paral- 
lel über mehrere angeschlossene Terminals und einer Stapelein- 
gabedatei ein schneller direkter Zugriff auf die Daten möglich. 
Die gerätetechnischen Mindestanforderungen (1 Direktzugriffs- 
speicher, 64 KB Hauptspeicher) erlauben einen Einsatz auf allen 
in der DDR. installierten Mikrorechnersystemen K1600. 


Bei der Entwicklung von KDS2000 wurden Erfahrungen aus der Ent- 
wicklung des DBBS DAFEMA berücksichtigt, so daß KDS2000 auf ei- 
nen ausbaufähigen bewährten Grundkonzept basiert. Der logischen 
Datenstruktur liegt ein relationales Datenkonzept zugrunde. Die 
interne Ablaufsteuerung erfolgt in Form einer Transaktions- 
steuerung. Der Anwender kann durch das Programmieren von eige- 
nen Transaktionen KDS2000 fast uneingeschränkt an seine spe- 
ziellen Problene anpassen. Bereitgestellte Makros unterstützen 
den Zugriff auf die Datenbasis und ermöglichen die Inanspruch- 
nahme weiterer Systemdienste. Grundfunktionen wie Zugriffs- 
schutz, Laden und Auslagern eines Datenbestandes und Blättern 
in bereitgestellten Bildschirmfolgen werden durch vorhandene 
Transaktionen realisiert. Im Rahmen der Weiterentwicklung von 
KDS2000 ist die Bereitstellung von allgemein nutzbaren Trans- 
aktionen für alle Grundfunktionen der Datenmanipuletion auf 
Satzebene vorgesehen. 


Der Einsatz von KDS2000 ale Komponente in verteilten Systemen 
ist in der 1. Ausbaustufe möglich, in den Daten eines zentra- 
len Datenbestandes ausgewählt und zum Mikrorechner übertregen 
werden. Dort werden sie unter Steuerung von KDS2000 zum Laden 
oder Modifizieren einer Datenbasis verwendet. 
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Die in der weiteren Arbeit vorgenommenen Anderungen oder der 
geänderte Datenbestand werden zum zentralen Rechner zurücküber- 
tregen und dort wieder in den zentralen Datenbestand eingear- 
beitet. = 


2. Dateisystem 


Für alle von KDS2000 verwalteten Dateien wird FCS als Zugriffs- 
methode verwendet. KDS2000 verwaltet die Datenbasis in einer 
Basiedatei und einer Suchdatei. Die eigentlichen Nutzerdaten 
werden in der Basisdatei gespeichert, Darin können bis zu 16 
logische Basisdateien (Datenbestände, Relationen) getrennt ver- 
waltet werden. Gegebenenfalls können in einer logischen Basis- 
datei auch mehrere Relationen abgespeichert werden. Die klein- 
ste edressierbare Einheit innerhalb der Basisdatei ist der Satz. 
Die Satzlänge ist variabel und beträgt maximal 500 Byte. Der 
Aufbau der Basissätze ist vollkommen wahlfrei. 


Sollen Datenbestände mit den vorgesehenen allgemein nutzbaren 
Transaktionen bearbeitet werden, müssen die Basissätze als Fol- 
ge von Feldern mit einer maximalen Feldlänge und Typattribut 
beschreibbar sein. Feldendekennzeichen für verkürzte Felder ist 
ein Tabulator. 


Der direkte Zugriff auf die Basisdatei wird über die Suchdatei 
ermöglicht. Die Suchdatei enthält die sortiert abgespeicherten 
Schlüssel mit zugeordneter Basisadresse :(invertierte Datei). 

Es können in der Suchdatei bis zu 25 logische Suchdateien ge- 
führt werden. Eine oder mehrere logische Suchdateien sind ein- 
deutig einer logischen Basisdatei zugeordnet. Die Suchdatei 
wird durch Vorgängerkompression speicherplatzsparend aufgebaut. 


Weitere Systemdateien sind: 


LOG-Datei 
Protokolldatei 
Stapeleingabedatei 
Blätterdatei. 


Der Anwender kenn in seinen Anwenderprogrammen (Transaktionen) 
beliebige Anwenderdateien verarbeiten. 
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3. Programnmsystem 


KDS2000 ist streng modular aufgebaut. Wir unterscheiden fol- 
gende in sich abgeschlossene Teilkomplexe: 


- Monitor 

- Basisdateiverwaltung 
- Suchdateiverwaltung 

- Transaktionssteuerung 


Der Informationsaustausch zwischen den einzelnen Moduln erfolgt 
über Steuerblöcke. In der 1. Ausbaustufe wird KDS2000 als Über- 
lagerungssystenm bereitgestellt. Eine Übersicht über das Zusam- 
mennirken der Teilkomplexe gibt die folgende Darstellung: 
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4. Implementierung 


Das größte Problem für den Anwender ist die Programmierung der 
eigenen Transaktionen. Es wird dabei durch das KDS-Makrosysten 
unterstützt. Folgende Systemdienste können über Makros ange» 
fordert werden: 


- Zugriff auf die Basisdatei 

- Zugriff auf die Suchdatei 

- Ausgabe auf Terminal oder Protokoll 

- Arbeit mit einer FCS-Anwenderdatei 

- Verwaltung von Informationen im dynamischen HS-Bereich 


In der 1. Ausbaustufe sind nur Makros für MAC1600 vorgesehen. 
Im Rahmen der Weiterentwicklung wird sich die Zahl der dem An- 
wender bereitgestellten nutzbarer Transaktionen für Grundfunk- 
tionen der Datenmanipulation erhöhen. 


Das Generieren des Hauptprogramms erfolgt mit einen Kommando- 
file. In einem programmgesteuerten Dialog werden vom Anwender 
Informationen über seine Transaktionen und weitere Generie- 
rungsparameter abgefordert, | 

Mit dem so erzeugten Programm KDS.TSK kann dann mit den einge- 
bundenen Transaktionen die Datenbasis aufgebaut und verwaltet 
werden. 


Zum Anlegen und Pflegen des Dateisystems steht das Dienstpro- 
gramm KDSSRV.TSK zur Verfügung, das folgende Funktionen reali- 
siert: 

= Anlegen der Systemdateien 
(Basisdatei, Suchdatei, LOG-Datei, Blätterdatei) 
Definieren’ der logischen Basis- und Suchdateien 
Auflisten der aktuellen Dateidefinitionen für Basis- und 
Suchdatei 
Sichern des Datenbestandes. 
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5. Weiterentwicklung 
Bei der Weiterentwicklung von KDS2000 wollen wir durch folgen- 


de Vorhaben die Leistungsfähigkeit und Nutzungsfreundlichkeit 
verbessern. 


1.) Schaffung von allgemein nutzbaren Transaktionen für alle 
Grundfunktionen der Datenmanipulation. 


2.) Erweiterung des Makrosystems und Entwicklung von Makros 
für komplexe Aufgaben der Datenmanipulation. 


3.) Schaffung von Anschlußmöglichkeiten für Anwenderprogramme 
in höheren Sprachen. 


4.) Herauslösen der Transaktionen aus dem Steuerprogramm ale 
selbständige Task. 


5.) Ermöglichung der parallelen Abarbeitung mehrere Trans- 
aktionen. 
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Werner, Klaus 


Probleme des Datenschutzes in relationalen Datenbanken unter Be- 


achtung der Schnittstelle zu statistischen Auswertungssystemen 


1. Problemstellung 


Moderne Informationseysteme werden in zunehmendem Maße zu notwen- 
digen Instrumenten und Werkzeugen des wissenschaftlich-technischen 
Fortschritts. Daraus ergeben sich aber gleichsam eine Reihe von 
Aufgabenstellungen - insbesondere für Ihformatiker und Okonomen - 
hinsichtlich des Entwurfe, der Gestaltung und der effizienten 
Nutzung dieser Systeme, 

Eine dieser Aufgabenstellungen betrifft die Fragen des Daten- 
echutzes. Genügte in der Vergangenheit, daß diese Fragen primär 
administrativ durch verwaltungstechnische Gesetzesregelungen, die 
sich zumeist auf die Deponie und die manuellen Zugriffe- und Aus- 
kunfterechte bezogen, abgesichert wurden, so gelten heute gänz- 
lich andere Prämissen, 

Zweifelefrei ist dabei die Zielstellung, der Schutz und die Si- 
cherung der Daten und Informationen vor Verlust und unzulässiger 
bzw. unberechtigter Benutzung, die gleiche geblieben. Wohl aber 
haben sich geändert 


- die Formen und Möglichkeiten der Erfassung, Abspeicherung, Än- 
derung und Auswertung der Daten, 


- die Kombinations- und Recherchemöglichkeiten von und in abge- 
speicherten Datenbeständen, 


- die Fragestellungen der Datenintegrität unter Beachtung dor 
Verflechtungsmöglichkeiten auf der Basis der Nutzung moderner 
Datenbank- und Dialogverarbeitungseysteme, ä 


N 


- die Möglichkeiten der Duplikat- und Teildatenniengenbtldung, 
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- die Formen und Methoden dee Zugriffs, insbesondere die Nutzung 
solcher Möglichkeiten, wie der Dialogverarbeitung, der Daten- 
fornverarbeitung, der Rechnerkopplung etc., 


- die Erfordernisse und Möglichkeiten der Nachweisführung über 
enteprechende Datenmodifikationen und -nanipulationen, 


dio Geachnindigkeiten in der Datenbereitstellung und 


- die Menge und Häufigkeit der anfallenden Daten und Informatio- 
. NONe 


Diese veränderten Konstellationen bedingen notwendigerweise auch 
andere Betrachtungsformen des Datenschutzes. Der Begriff Daten- 
echutz eoll dabei einmal in seiner umfassenderen allgemeinen Be- 
- deutung und zum anderen, bezogen auf die nachfolgenden Ausfüh- 
rungen, in einem engeren Sinne verstanden werden. 

In eeiner allgemeinsren Bedeutung bilde der Datenschutz die Ge- 
samtheit der Standards und gesetzlichen Regelungen zur Durch- 
setzung und Realisierung schutzwürdiger Belange bei der manuel- 
len, maschinellen und automatischen Ermittlung und Bearbeitung 
bzw. Nutzung von Daten und Informationen. 

Im engeren Sinne 'beinhalte er die Kontrollierbarkeit und Steue- 
rung bzw. mögliche Protokollierung der Zugriffe zu Daten und In- 
formationen, die in Datenbanken oder Dateien gespeichert sind 

und über Dialog-, Datenfern- oder herkömmliche Jobverarbeitung 
‚abgerufen oder modifiziert werden sollen, mit rechentechnischen 
Mitteln dee Betriebs-, Datenbank- und/oder Anwendungssystens. 
Aufgabenstellungen dieser Problemkreise werden integrale Bestand- 
teile der Informationssysteme, und es gilt, die Mittel und Mög- 
lichkeiten der modernen Informationsverarbeitung Zu nutzen, um 
auch hier entsprechende Lösungen anzubieten. 

Eine zentrale Stellung in diesem Zusammenhang nehmen die Daten- 
banken ein. Sie stellen im weitesten Sinne eine moderne rechen- 
technische Realisierung der Speicherung von, der Änderung von und 
des Komplexzugriffs zu Datenbasen dar. Aus der Sicht der Informa- 
tik ergibt sich daraus die Aufgabenstellung, den Anwendern dieser 
Datenbanken Schutz- und Sicherungsmechanismen anzubieten, die 

0. g. Zielstellungen erfüllen. 
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Die Vielfalt der existierenden Datenbanksysteme unterschiedli- 
cher Modelle und deren konkrete Implementierungen lassen dies zu 
einer komplexen Aufgabenstellung warden, deren Lösung eine inter- 
disziplinäre Arbeit erfordert. Aus dem Blickwinkel dee Informa- 
tikers scheint es erforderlich, zu untersuchen, 


= welche konkreten Schutzmechanismen für die unterschiedlichen 
Datenbankmodelle bzw. -systeme existieren, erforderlich bzw. 
möglich sind, 


- welche Schnittstellen einmal zur Betriebssystemungebung und zum 
anderen. zu entsprechenden Auswertungssystemen gegeben oder 
festzulegen sind, 


- welche Zugriffsverfahren und -methoden für welche Schutzbelange 
geeignet und nutzbar sind und 

- welcher Grad der Verallgemeinerung dieser Lösungen hinsichtlich 
der einzusetzenden bzw. existierenden Datenbanksysteme notwen- 
dig ist. 


Im Rahmen dieses Beitrages seien einige Bemerkungen zur Problenma- 
tik des Datenschutzes in relationalen Datenbanken unter besonde- 
rer Beachtung einer möglichen Schnittstelle zu einem statisti- 
schen Auswertungssystem gemacht. Die angebotenen Erkenntnisse 
basieren auf entsprechenden Studien und noch nicht abgeschlosse- 
nen Untersuchungen dieser Problematik im Rahmen einer vorzulegen- 
den Dissertation zu einem gleichartigen Thema. Sie sind deshalb 
als ein Problembeitrag und nicht als eine Problemlösung anzusehen, 
Als Datenbanksystem steht MIMER (relationales Datenbanksystem der 
Universität UPSALA in Schweden) zur Verfügung und als entspre- 
chende Auswertungssysteme bisten sich an PP-Statistik, SPSS, BMDP 
oder SAS. 


2. Probleme des Datenschutzes in relationalen Datenbanken 
Das relationale Datenmodell oder Relationenmodell wurde von CODD 


(1970 bzw. 1979) beschrieben. Es ist im wesentlichen inhalts- 
orientiert und grundsätzlich nicht zugriffspfadabhängig, d. h. 
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sowohl für das Abspeichern und Wiederauffinden von Daten ist der 
Inhalt der Datenstruktur von Bedeutung und keine bestimmte Zu- 
griffsfolge. Eine Datenstruktur wird im relationalen Modell als 
eine Relation bezeichnet. Ein wesentlicher Gesichtepunkt bei Da- 
tenstrukturen des relationalen Modells sind die Operationen über 
diesen Datenstrukturen, Auch dadurch wird deutlich, daß Relatio- 
nen in gewisser Weise verwandt sind mit Datenmatrizen und demzu- 
folge für statistische Auswertungen gut geeignet scheinen, 
Neben den allgemein bekannten und in den meisten Betriebssysten- 
umgebungen reslisierten Möglichkeiten der Identifikation, der 
Authentifikation und der Autorisierung els Standarddatenschutz- 
algorithmen scheinen sich insbesondere bei relationalen Daten- 
banken eigenständige Mechanismen einer Zugriffskontrolle anzu- 
bieten. Dabei bedingt eine derartige Zugriffekontrolle zweierlei 


- ein entsprechendes Kontrollsyetem und 
- dazugehörige. Zugriffsbeschreibungen. 


In der Literatur werden. Systeme, in denen man die einem Benutzer 
nicht zugänglichen Daten in den sogenannten Zugriffsbeschreibun- 
gen festlegt, als offene Systeme bezeichnet. Geschlossene Systeme 
liegen dann vor, wenn nur die dem Benutzer zugänglichen Daten be- 
schrieben sind (need-to-know-Prinzip). 

Beide Kontrollstrategien sind durch logische Operationen inein- 
ander überführbar, so daß eine ausschließliche Festlegung auf 
eine der Strategien nicht erfolgen muß. 

Das Kontrollsystem muß integraler Bestandteil des Datenbankbe- 
triebssystems sein, während die entsprechenden Zugriffsbeschrei- 
.bungen im Sinne der logischen Datenbeschreibungen in der konzep- 
tu .ellen Ebene getrennt erfolgen können. 

Dabei bietet es sich an, diese Datenbeschreibungen ebenfalls in 
Form von Datenstrukturen (Relationen) darzustellen (etwa wie in 
MIMER v. 3). Diese Relationen widerspiegeln sinngemäß die von 
Prof. Dr. Wedekind theoretisch untersuchten Zugriffsmatrizen. In 
diesen werden funktionale Subjekt-Objekt-Beziehungen ale Zu= 
griffebeschreibungen genutzt. Dabei gilt es insbesondere bei die- 
sen funktionalen Subjekt-Objekt-Beziehungen zu unterscheiden 
zwischen 
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- wertunabhängigen und 
- wertabhängigen Datenobjekten. 


In MIMER ist es notwendig, dem Kontrollsystem -mwertunabhängige 
funktionale Subjekt-Objekt-Beziehungen anzubieten, 
Prof._Dr. Wedekind schreibt, daß eine Umwandlung wertabhängiger 
in wertunabhängige Datenobjekte einmal durch "Manualisierung” 
oder zum anderen "zusätzliches Anlegen von Datenobjekten" mög- 
lich ist. 

Methoden der zweiten Variante sind zum Beispiel: 


- eine inhaltsabhängige Zugriffskontrolle 
Im Sinne der Operatoren über dem Relationennmodell entepräche 
dies einer Reatriktion (oder auch where-condition bei MIMER 
beispielsneise), d. h. einer horizontalen Teilmengenbildung. 
Aus einer gegebenen oder erzeugten Relation werden definierte 
Tupel ausgewissen, 
Sie beinhaltet typische Eigenschaften eines geschlossenen 
Systens. 


- die kontextabhängige Zugriffskontrolle 
Darunter soll eine vertikale Mengen- bzw. Teilmengenbildung 
beispielsweise durch die Operatoren Projektion oder Join ver- 
standen werden, Typische Eigenschaften offener Systeme sind 
erkennbar. 
In der praktischen Realisierung findet man häufig Konbinatio- 
nen von inhalts- und kontextabhängigen Zugriffsmechanismen. 


- die. ablaufabhängige Zugriffskontrolle 
Ein Vorteil des relationalen Datenbanksystems ist, daß die 
Datenstrukturen (Relationen) relativ unabhängig voneinander 
existieren, sie aber sehr leicht kombinierbar miteinander sind. 
In analoger Weise lassen sich andererseits durch die Projektion: 
Teile der Datenbank als neue Datenstrukturen herausfiltern. 
Die ablaufebhängige Zugriffskontrolle geht nun davon aus, daß 
ein Nutzer zwar auf definierte Datenstrukturen einzeln zu- 
greift, sie aber nicht beliebig kombinieren darf. 
Weiterreichende Ausführungen dazu sind zu finden in: 
HARTSON H.H., HSIAO D.K,, 
"A Semantic Model for Data Base Protection Languages" 
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- die funktionale Zugriffskontrolle 

Mit dieser Art der Zugriffskontrolle beschäftigen sich unter 
anderem DENNING D. E., DENNING P. I., SCHWARTZ M. D. in ihren 
Beitrag: "The Tracker: A Threat to Statistical Data Base 
Security”. 
Es geht dabei um die Kontrolle des Zugriffe auf Daten, die 
nicht einzeln, eondern in Form von Zusammenfassungen oder von 
etatistischen Auswertungen dem Benutzer zugänglich gemacht 
werden. Also das Durchechnittsalter der gerade anwesenden Damen 
derf man gerade noch nennen, das Alter einer einzelnen Dame 

. sollte aber anonyn bleiben, 


‚Insbesondere die letztgenannte Zugriffsekontrolle verdeutlicht 
Gonpinsankeiten von Problenen des Datenschutzes in reletionalen 
Datenbanken und zum Beispiel statistischen Auswertungssystemen, 


3. Statistische Auswertungssysteme und mögliche Schnittstellen 
zu relationalen Datenbanken 


Auswertungssysteme sind eine Untergruppe rechnergestützter Infor- 
nationseysteme. HAUX definiert sie in seiner Dissertation zum 
Thema "Die. Verwendung komplexer Datenstrukturen in statistischen 
Aubwertungssystemen” wie folgt: 


‚Ein Auswertungssystem A ist definiert durch: 
A = (Db, Mb, Ss, DMbvs) 


wobei 
j “ Dbz die Datenbank, 
Mb: die Methodenbank, 
Se: die Menge der Schnittstellen und 


DMbvs; das Daten- und Methodenbankverwaltungssysten 
von A sind. 


In der gleichen Schrift definiert er ein statistisches Auswer- 
tungseysten, indem er schreibt, es sei ein Auswertungssystem ge- 
mäß 0. g. Definition, welches in seiner Methodenbank - im wesent- 
lichen - Methoden enthält, die zur Datenanalyse mit statistischen 
Verfahren dienen. 
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Es liegt auf der Hand, daß diese Begriffsbestimmung eine Ziel- 
stellung für den Aufbau eines statistischen Auswertungssystems 
etwa im Sinne von 


- MEDUSA (Kopplung von NATURAL - einer Softwareumgebung .von 
ADABAS - mit SAS) oder 


- RAMIS (Schnittstelle zwischen dem Datenbanksystem RAMIS und 
dem System SAS) 


darstellt, wir aber derzeit davon ausgehen können, daß Datenbank 
und das Spektrum der Methoden - im allgemeinen noch nicht als 
Methodenbank zu bezeichnen - unabhängig voneinander existieren 

. und als mögliche Schnittstelle eine gemeinsame Datei angesehen 
werden kann. Diese Datei wäre .nun denkbar als eine Datenstruktur 
'im Sinne des relationalen Datenbanksystems. 

Eine. Zielstellung des Datenschutzes bei statistischen Auswertun- 
gen ist die Minimierung des Identifikationsrieikos, d. h. aus 
den in Ergebnis der Anwendung der statistischen Methoden und Ver- 
fahren resultierenden Datenstrukturen sollte ee im allgemeinen 
nicht möglich sein, auf konkrete Subjekt-Objekt-Beziehungen zu 
schließen. j 

-Hierfür werden in der Literatur eine ganze Reihe von Möglichkei- 
ten aufgezeigt. FELLEGI I. P. nennt in eeinem Bericht: "On the 
question of statistical confidentiality”die Methoden der Daten- 
reduktion. Zu ihnen zählen 


.= die Verwendung einer Stichprobe ale Datenstruktur, 
- die Entfernung konventioneller Identifikatoren, wie Name, 
Adresse, Geburtedaten etc., aus der Datenstruktur und 


- die Anonynität der Stichprobe, 
Gerade hier acheinen relationale Datenbanken gut geeignet, der- 


artige Stichproben in Form von Relationen und. damit letztlich 
Tabellen den Auswertungssystemen anzubieten. | 
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Auch die von SCHLÜRER genannten zwei Formen der Outputkontrollen 


- die Output-Selektion und 
- die Output-Modifikation 


bieten durchaus gute Ansätze, einen statistischen Auswertunge- 
dialog mit einer entsprechenden Stichprobe in Form einer defi- 
'nierten Datenstruktur zwar nicht umfassend aber doch ausreichend 
zu sichern. | 

Auf dieser Ebene praktikable Lösungen in naher Zukunft zu errei- 
chen, sollte möglich sein - den Blick in diese Richtung zu lenken, 
wäre eine Zielstellung dieses Aufaatzes. 


Dipl.-Ing. Klaus Werner 
Karl-Marx-Universität Leipzig 
Organisations- und Rechenzentrum 
Karl-Marx-Platz 10/11 

7010 Leipzig 
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Zinmerling, Roland 
Müller, Dietmar 


LEISTAR - eine relationale Datenbanksoftware für Anwendungs- 
programmierer ? ' 


1. Vorbemerkungen 


Zur Rationalisierung konstruktiver und tachnologischer Pro= 
zesse werden zunehmend automatisierte Informationssystens 
(AIS) eingesetzt. Die für diess Prozesse benötigten großen 
Datenmengen lassen sich effektiv nur äurch Datenbanksystena 
verwalten. Dabei wird ein Datenbanksystem in oinenm AIS der 
teohnischen Produktionsvorbereitung nicht nur in direkter 
Kommunikation mit dem Endnutzer als Auskunftssystem (Infor- 
mationsrecherohesystem) genutzt, sondern verstärkt zur. Da- 
tenverwaltung in problemorientierten Programmpaketen eingo- 
setzt. Die im zentralen Datenspeicher enthaltonen Informa- 
tionen, die traditionell vom Endnutzer nur durch Informa- 
tionsrecherche ausgewertet wurden, sollen also auch Problem- 
progranmen verfügbar gemacht werden. Für diese Nutzungaforn. 
bedarf es einer Schnittstelle, die vom Anwondungsprogrammiorer 
in oeino problemorientierte Programmiersprache eingebottet 
werden kann. z 

Hinsichtlich des Mehrebenenarchitekturprinzips von Datenbank- 
betriebssystemen ist diese Schnittstelle, die dio problem 
unabhängigen Datenbankfunktionen realisiert, auf der kon- : 
zepiuellen Ebene einzuordnen und soll der problemnahen Schnitt- 
stelle eines Datenbankkerns (DBK) entsprechen (vgl. ZIEMERLING 
83 und MÜLLER 84). 


2. Die LEISTAR-Schnittstell 


Relationale Datenbanken setzen sich rınch im kommerziellen 
Bersich immer mehr durch. Sie werden für üle versch”edensten 
Anwendungen genutzt und worden Bestandteil (Tallsystem) von 
Expertensystemen sein. j . ’ 
Zur Grundausstattung der 5. Rechnergeneration gehören voraus- 
sichtlich Datenbankmaschinen, die die Relationenalgebra nach 
CODD (vgl. CODD 71) als Schnittstelle anbieten. 


Aufgrund dieser international zunehmenden Bedeutung relatio- 
naler Datenbanksysteme wurde für die LEISTAR-Operationen die 
Relationenalgebra zugrunde gelegt. i 


LEISTAR realisiert im Unterschied zu solohen Datenbanksystemen, 
die ebenfalls eine Schnittstelle für Anwendungsprogramierer 
bereitstellen, 


- alle Operationen der Relationenalgebra, 

- echte Nehrtupelverarbeitung, 
(zum Vergleich — IIILER/DB realisiert nur Eintupel - also 
an Verarbeitung) 

- die Verarbeitung unformatierter, variabel langer Werte. 
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Das Ergebnis einer Zugriffsoperation (Operation. der Rolationen- 
a ee Er ae s Tabolle, die für üle Dauer der 
Auf diese temyorKren Taballen können wiederum Zugriffsopsratio- 
nen angewandt werden. 


Neben diesen Zugriffsoperationen wnfaßt dar Oparationmumfang 


= beschreibende Operatlonen, 
- Eingabeoperatlionen 


- sine Ausgabeoperation, 


- Operationen gum Ändern von Tabellen und Spalten, 
‚= Serviceoperationen und 


= Operationen Über Datenbanken, ä 
Die Paraneter der nachstehend aufgeführten Operationen bedeuten: 


DBNAHM None siner Datenbank 
DATE Bearbeitungsdatum 
TABNAM Name e3ner Tabelle/Relation 
R (bzw, Ergebnistabelle -— gilt aber nur für die 
Zugriffs-, Ausgäbe- ımd Serviccoperatlionen) 
SPANAH Name einer Spalte/eines Attributes 


ALINAU Neans eines Spaltensmmonms _ i 
WERT Ein- bzw. Ausgabefeld; Vergleichsweort 
vor Vergleichsoperator . 


ANZTUP ‚Ansahl der Tupel einer Tabslle 
ERGTAB .. permanente oder tenmorire Ergeimistabella 


SKZ :. . Schlleselkimnzöfchen 
HASSEH Maßeinheit 
BC Rückkehreode 


Die wnterstrichenen Parameter sind Ausgabeparaneter. 
221. Zugriffsoperatlonen 


SELECT (TABNAN, SPANAL, VOP, WERT, ANZTUP, TROMAB, RC) 
RESEIRI (TABNAI, SPANAT, VOP, SPANA2, ANZUWUP, ERGTAB, RC) 


JOIN. (TABNA1, SPANA1, VOP, TAMMA2, SPAIAD, ANSTUP, ERCTAB, RC 
DIVIS (TABNA1, SPaAl, TABNA2, SPANA2, AUZTUP, ENG . 


PROJEC (TABNAM, SPAVER, AlZSPA, ANZTUP, TC) 
MENGOP (TABNA1, MOP, TABNA2, ZNZTUP, ERGTARB, RC) 


VOP = EQ, NE, GT, I, IE, c5 
MOP = IN, WI, II 
\ LIDNUS 
UNION - 
TIMERSEOHTION 
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2.2. Beschreibende Operationen 


DEPTAB (TARA, RC) | 
« Aktiviert das Definicren einar Tabollo 


DEPSPA (TABNAU, SPANAL, SKZ, DORINT, LATIGE, MASSE; RC) 
a.aies, fi cine Spälto 
SKZ = > 
„ws 
8 an wenn PORIAT = une dann 
DAnıE = z tyA! oblgt Senn, 
DEPALT (SARA, SPAHAN, ALDI, RC) 
e Dofiniort oin Spaltonoynonyn 
DEPEND (TABMALU, RC) 


» Schließt das Definioren oinor Takelle ab 
- » das Dofinieren allor Priniterchlliogel muß vor 
3 Ausführımg disser Operation abgeschlossen zein 


Luc u Su Su) 


2.3. Anzeigen der Tabellenboschreibung 


DESTAB (TARHAI, ANZTUP, ANZSPA, MATT, RC) 
Gibt Anzahl dor Tupol, dor S ton et das 
* Aktunliniormgeäntun cin tr 


DESSPA (TAN, 1, SPAIATT, ST, FORS,, TAROT. TMSSEH, RC) 
» cibt Be A165 Speltenparangter a Hann dar 


DESUD (Arhrman, Dar, R6) 


„ itbt dia Ancahl dar Tnbollen imd dus Donzbettunge- 
datum oinor Datenbanlz aus 


DESDE2:. 1, SAHTAH. RC) 
+ Gibt den Icon der T-ten Tabolla aus 
DESALI (TÄINAL, SPATAU, ANZALT. RO) 
« Gibt dio Ancahl dor Synonyms für edno Spaltg sus . 


DESAL2- (TABNAIN, SPAHAN, II, ALKTA, RC) - 
. Gibt don Tanen den I-tom. ‚Spaltonaynonyma aus 


2.4. Eingabeoperationen 
SETZEI (TABNAN, RC) 
| . Aktiviort ein noues Tupol 
FUTSPA (SPANAM, WERT, RC) 
 . Speichert genau einen Spaltenwert in das aktiviorte Tupol 


2.5. Ausgabeoperationen 
PABOUT A(TABNAM, SPAVEK, ANZSPA, N, WERT, RC) 


„ Gibt die Werte der in SPAVER een Spalten den 
N-ten Zupol aus 


2.6. Operation-zum Ändern von Tabellen 
DELTAB (TABNAH,. RC) 
» Lösoht aino Tabälle! ‚ginsohließlich. ‚deren Beschreibung 
DELCON ' (TABNAN, RC) 
s Löscht nur den Inhnlt einer Tabello- 
DELZEI : (TAHNAM, ERGTAB, RC) | 
. en die durch Recherche spezifizlerten Tupel in 


ADDSPA (TAHNAH, SPAHAN, SKZ, FORMAT, LAENGE, MASSEH, RC) 
- Fügt o Tabelle TABNAM eina Spalto an 
er: 


zuge. (TABNAM, SPAHAI, RC) 
+ 'Löscht die Spalte SPANAU in der Tabelie TAHNAN i 
(allo Werte einschließlich deren Spältenbeschroibung) 
UPESPA (TABNAU, SPANAU, ERGTAB,. WERT, RC) 


. Auagrt. dio Spaltonwerte der Spalte SPANAN 
en durch Rechsrcha ap ziaorten Tupeln 
Aa Tabelle TABNAU 
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2.7. Scervioeoparationon 


PEHPER (ZURGSAB, STAVEX, ANZSPA, TURN, RC) 

. ÜberZührt die taumporüro Ergeinistabello ERCTAB 
in dio permmnentea Tabello TARA nit Ausmtl von 
Spalten { 

SORTAB rege SPAVET, AUZSPA, SOFO, FREMAR s RC) 
Sortiert oin  uzeı baol. nohrirer Spalten. 
. S0F0 « IST, R 
DUPLI (HABA, SPANAH, AUZSUP, IAUYrAD, RC ) 
. Beseitigt er beste aluer Spalte 


2.8. Operationen Uber since» Datenbank 
DBOPEN (DEMAN, DATE, IODUS, RC) 
. Eröfinet cino Dutonbank 
. MODUS. = IDP, uf, ar 
L— morhandene IB aUemnen 
Anitialisieren 
definieren 
DBSLOS (DEMAN, RC) 
. Schlisßt eine Intenhmk nach Boendimmg - 
der Sitzung ab 


DBCOLY (DBZIEL, DEQUEL, EG) 
. Kopiort eins Datenbank 
3. _ Dio Datenbanksoftture LEISTAN 


LEISTAR wurde in FORTRAT inmlonsutiort. Die reale ie 
können nlo Untorpropversto In FORMUN“Pro, 


. Div WTISAR-Intoryrogrenno ep 3 und betertobo- 
oyotemmi und künnen an verschioedand Spolcharuystono 
(05, 05, ent) engepadt warden. 

Alle Onerationen nilsyen iu DSOPSI md ne schlosuen 


sein, und beziehen sich cur? cine Dutenbenk. Inuorlu oinor 
Datenbanl: (eine Datembeni: outspricht einer Di-Da DanDatei können 
beliebig viele Tabellen doZiniort und maniruliaort werden. 

In einor Tabelle kümen bolichbig violo Sr Sen a Est wor 
den, dlo formatiert bar. unformatiert oc 
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Die £cat Lormntierten Spalten Iunen vom Mm, ‚REAL, DNGCER. 
odar CHARACTER und maximal 255. Byto lang o * Spalten (außer 
Prirärg wunf deren 


ehllissel) können auch rmntiorh San 
Zeitpunkt Sr Am Ant und wird 
nit 'VAr (= variabel) spe — 


j e arreichen, Durch das Diutragen eines opeziollen Opcru> 
tionssodas, von Position und Iän ‚in einen CALIOI=Beroich 
-köunen imerhalb der unfonmt seven Spalto bollocbige nn 


cingsfügt, efügt, en warden. 
oiner eolshen uf en sch bare gelenen in jed u 
vorzchiedon lang sein, 


Die Software von LEISTAR l1iogt in wodularer Form vor. Das 
holßt, vom Anwendungsprograumtlerer brauchen noben eine bo» 
otimt LEISTAR-UoduIn : 

dio benötigten Operationen realisioren, mm Anvendungapro- 
cram dazu vorbunden werden. Der Inumta ichorbedcer? 

also von er dor bondtigten-Loduln md betrigt für die 
Sumo aller lioduln 120 K Bıytc. 


I: vie 
Yach der m celcs ein Dinloges wurda 
LEISTATr erfolgreich in der Ichre gmutzt. 

Weitere intergoktionelle Anwendungen werden realisiert br 
sind An Vorbereitung. 
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Zschockelt, Peter 


Informatiönsorganisatorische Anforderungen an verteilte Daten- 
banken aus der Nutzersicht volksnirtschaftlicher Querschnitts- 
aufgaben i 


1. Zum Verhältnis der Informationsorganisation zur Datenkommu- 
nikations-Software und Hardware 


Ein wesensbestimmendes Merkmal der Software besteht in der Ma- 
terialisierung der Organisation von Informationen und Informa- 
tionsverarbeitungsprozeassen; Informationen aber sind immer an 
die ihnen zugrunde liegenden Basissysteme/ -prozesse gebunden 
(vgl. auch /1/). Die damit verbundene Wechselmnirkung zwischen 
Basissystem/ -prozeß und Information wird durch die Inhalt-Fornm- 
Dialektik bestimmt. Daraus folgen zwei grundsätzliche Aussagen: 


1. Die Anforderungen der mittels automatisierter Informations- 
verarbeitung (AIV) zu rationalisierenden Aufgabenlösungen 
bestimmen wesentlich die notwendige Organisation der Infor- 


mationen und damit auch die erforderliche Software. Die volks- 


wirtschaftliche Effektivität der Softwareproduktion hängt da- 
bei in großem Maße davon ab, inwieweit es gelingt für ty- 
pische Aufgabenklassen anpassungsfähige aufgabenklassenspe- 
zifische Software (im Gegensatz zur Einzellösung einer kon- 
kreten Rationalisierungsaufgabe) bereitzustellen. 


2. Die Anwendung der AIV ermöglicht ein neues qualitatives 
Niveau der informationellen Gewährleistung der Basissysteme/ 
-prozesse. Software und die zur Anwendung der Software erfor- 
derliche Informationsorganisation werden damit neben der 
Hardnare zu einem wesentlichen Faktor der weiteren Entwick- 
lung der Basissysteme/ =Prozesse. 


Für eine hypothetisch vorausgesetzte Aufgabenklasse "Rationali- 
sierung volkswirtschaftlicher Querschnittsaufgaben" bedeutet das 
konkret: Die in der Literatur dargestellte Arbeitsmittelfunktion 
der Software erfaßt einen zweifellos wesentlichen Aspekt, reicht 
jedoch zur Charakterisierung der informationellen Gewährleistung 
komplexer Leitungssysteme nicht aus. Der Nutzen, der primär auf 
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die Effektivität der Arbeitsmittelfunktion der.Software gegründe- 
ten Anwendung der AIV für die sozialistische Gesellschaft, be- 
steht in der unmittelbar möglichen Steigerung des Produktivitäts- 
niveaus. Die Nutzung technologisch ausgereifter internationaler 
Software (ebenso wie der Export derselben) ist dabei durchaus 
möglich und kann zu beträchtlichen Effektivitätszuwachs führen. 
Wesentlich darüber hinausgehend ist aber der strategische Charak- 
ter der Fragestellung nach dem Verhältnis zwischen Leitungs- und 
Informationsorganisation innerhalb des volksmirtschaftlichen Lei- 
tungssystems, weil die von der AIV ausgehenden qualitativen Ein- 
flüsse in Wechselwirkung mit dem grundlegenden Organisationsprin- 
zip der Wirtschaftsleitung im Sozialismus, dem Prinzip des demo- 
kratischen Zentralismus, stehen. Die Software als elementare 
Voraussetzung jeglicher AIV realisiert unter diesem Gesichts- 
punkt also zugleich wesentliche materielle Bedingungen für die 
weitere Entwicklung des Systems der Wirtschaftsleitung. Die in 
den Dokumenten der SED geforderte Realisierung volkswirtschaft- 
lich durchgängiger Annendungslösungen der AIV (vgl. /2/), ist 
folglich zwar auch ein Problem der ökonomischen Wirksamkeit der 
Rationalisierung von Leitungsprozessen im Sinne der Effektivität 
von Arbeitsprozessen, jedoch in für die sozialistische Gesell- 
schaft bedeutenderem Maße eine Grundfrage der informationellen 
Gewährleistung der nach dem Prinzip des demokratischen Zentra- 
lismus organisierten Leitungsprozesse durch Software, die die 
Fähigkeit zur Zentralisierung und Dezentralisierung von Infor- 
mationen besitzt. Das aber ist genau eins der wesentlichsten Ei- 
genschaften verteilter Datenbanken als Bestandteil lokaler‘'und - 
globaler Datenkommunikationssoftware (vgl. Konzept der Computer 
Communication Software (CCS) in /3/). Die Ausarbeitung der in- 
formationsorganisatorischen Anforderungen an verteilte Daten- 
banksysteme aus der Nutzersicht definierter Aufgabenklassen ei- 
nerseits und die Schaffung der 8oft- und hardwaremäßigen Voraus- 
setzung für den Batrieb verteilter Datenbanken sind somit sich 
notwendig ergänzende Bestandteile der volkswirtschaftlich ef- 
fektiven Nutzung dieser zukunftsträchtigen Anwendungsform der 
AIV. Die frühzeitige Orientierung auf die Lösung dieser Proble- 
matik ist zugleich von erheblicher praktischer Bedeutung. So 
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birgt beispielsweise eine ausschließliche Dezentralisierung der 
‚informationellen Gewährleistung von Leitungsprozessen in Form 
autarker Anmendungslösungen auf BC- Basis (und in der Folge, die 
mangelnde zentrale Vergleichbarkeit und Aggregationsfähigkeit von 
Datenbeständen, die behinderte zentrale Zugriffsmöglichkeit zu 
Daten, die fehlende Integrationsfähigkeit dezentraler Datenbasen 
usn.) durch die starke Einbindung in die geistigen Arbeitsprozes- 
se der Menschen die Gefahr in sich, für langfristige Zeiträume 
die Möglichkeiten der AIV für die sozialistische Gesellschaft 
nicht im erforderlichen Maße auszuschöpfen. 


2. Informationsorganisatorische Grundfunktionen verteilter Da- 
tenbanken aus der Sicht volksmwirtschaftlicher Querschnitts- 


aufgaben 


Die Grundanforderung an verteilte Datenbanksysteme besteht in 
der hohen Verfügbarkeit der in der Datenbasis des System gespei- 
cherten Informationen. Im Gegensatz zu konventionellen Daten- 
banksystemen wird diese hohe Verfügbarkeit nicht primär durch die 
Steigerung der Zuverlässigkeit jeder einzelnen Komponente des Da- 
tenbanksystens, sondern durch die Kombination der Komponenten der 
verteilten Datenbank (Netzknoten und Kommunikationskanäle) ange- 
strebt (vgl. /4/). Der Begriff der Verfügbarkeit unterliegt ins- 
besondere hinsichtlich 
- des Umfanges, der Struktur, der Systematisierungs- und Kombi- 
natsfähigkeit von Daten und 
- des Zeitfaktors für die Realisierung der Verfügbarkeit 
einer aufgabenklassenspezifischen Modifikation. Aus ihr leiten 
sich konkrete Annenderforderungen vor allem hinsichtlich der Auf- 
teilung des Datenbestandes auf die Netzknoten und hinsichtlich 
des Ausgestaltungsgrades der einzelnen Funktionsarten eines ver- 
teilten Datenbanksystems ab. Bezüglich der hohen ökonomischen 
Anforderungen für die Installation und den Betrieb verteilter 
Datenbanksysteme sind unter diesen Gesichtspunkten effektive An- 
wendungslösungen notwendig. Unter diesem Ziel sollen die wesent- 
licheten informationsorganisatorischen Besonderheiten der Aufga- 
benklasse "Rationalisierung volkswirtschaftlicher Querschnitts- 
aufgaben“ für folgende Datenbankfunktionen diskutiert werden: 
1. Datenverarbeitungsfunktionen,° 
2. Zugriffsfunktionen, 
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3° Transportfunktionen, 
4. Funktionen zur Sicherung der Datenintegrität. 


Zu_den Datenverarbeitungsfunktionen: 


Hierunter sei besonders auf die Verteilung der Daten auf die 

Netzknoten verwiesen. Die Spezifik der Aufgabenklasse besteht 

derin, daß 

- eine Datengesantheit mit höchstem Detailliertheitsgrad an der 
Basis (Betrieb/Einrichtungen) existiert, 


- entsprechend den Leitungsebenen eine Datenverdichtung nach 
den Prinzipien der Selektion, Aggregation und Kennziffernbe- 
rechnung erfolgt, jedoch die Identifikation der Daten durch 
zusätzliche Identifikatoren notwendig wird, 


- entsprechend den Leitungsebenen die Anforderungen an die ter- 
minliche Aktualität der Daten sinken (Langfristigkeit globaler 
Entscheidungen), 


- nicht für jede Leitungsentscheidung die komplette Datengesamt- 
heit notwendig ist (Stichprobenprinzip) und 


- ein zuverlässiger Schutz der zentralisierten Datenbestände vor 
unkontrollierten dezentralen Zugriffen gewährleistet sein nuß. 


Diesen Besonderheiten entspricht eine weitestgehend primärdaten- 
orientierte Datenbasis, die aus einer Hierarchie 


a) durchgängig bis zur zentralen Leitungsebene verbindlicher In- 
formationen (zentral notwendiger Informationsfonds), 


b) für die dezentralen Netzknoten fakultativer, jedoch nach ver- 
bindlichen zentralen Regelungen organisierter Informationen 
(zentrale Informationsreserve) und 


c). dezentral nach autarken Regelungen organisierter Informationen 
(dezentrale Ergänzungsinformationen) 


besteht. 

Die Verwaltung einer solchen Datenbasis ist durch die Führung : 
ebenengebundener Datenkopien und deren rhythmische (z. T. nur in 
größeren Zeitabständen notwendige) Aktualisierung in definier- 
ten Teilmengen möglich. Dabei gilt der Grundsatz, daß die Daten- 
aggregation und Kennziffernbildung, jeweils im Netzknoten der hö- 
heren Leitungasebene erfolgen sollte, um notwendige Veränderungen 
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auf diesen (einen) Knoten zu lobalisieren. 
Notwendige Bedingungen dieses Konzeptes sind ein für alle Netz- 
knoten einheitliches systematisierungsfähiges Schlüsselsystem 
und einheitliche Definitionsvorschriften für die Erfassung und 
Darstellung der Informationen (Entitäten). 


Zu _ den Zugriffsfunktionen 

Entsprechend dem dargestellten Konzept sollte angestrebt werden, 
Zugriffe mit hoher zeitlicher Priorität (Sofortzugriffe für Re- 
cherchen und andere operative Leitungsentscheidungen) prinzi- 
piell auf die an den einzelnen Netzknoten verfügbaren Datenko- 
pien zu begrenzen. Der Zugriff zu den zentralen Informationsre- 
serven bzw. zu zentral den dezentralen Datenbasen beraitgestell- 
ten Informationen kann über die Nutzung der Transportfunktionen 
mittels temporärer Kopien erfolgen. 


Zu_den Transport funktionen 


Die Transportfunktionen sind nutzbar. für 
- die Aktualisierung der Datenkopien auf den Netzknoten höherer 
Leitungsebenen in definierten Teilmengen, 


- den Zugriff zu zentralen Informationsreserven und 


- die physische Realisierung eines einheitlichen konsistenten 
Schlüsselsystens. 


Die relativ geringen Anforderungen an die zeitliche Aktualität 
der Datenbasis (z. B. generelle Nutzung von Nachtzeiten) gestat- 
tet dabei effektive Lösungen für die Nutzung territorial und/ 
oder zweiglich organisierter Datenkommunikationssysteme auch für 
volkswirtschaftliche Querschnittsaufgaben. 


Zur Sicherung der Datenintegrität 


Die große Dimension der für die Aufgabenklasse notwendigen Da- 

tenbestände erschwert die Wahrung der Datenintegrität beträcht- 

lich. Sie sollte deshalb konzeptionell 

- auf der Ebene der Primärdatenerfassung als komplexe Integri- 
tätskontrolle, 


- auf der Ebene der Transportfunktionen als Datenprüfung beim 
Sender und als operationelle 'Integritätskontrolle beim Enpfän- 


\ 


ger 
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organisiert werden. 


3. Ein Vorschlag für das logische Datenaustauschfornat 


Für den Transport der Daten zwischen den Netzknoten und für die 
darauf aufbauende Aktualisierung der Datenkopien auf den unter- 
schiedlichen Netzknoten empfiehlt sich ein universelles logi- 
sches Datenaustauschformat, das folgende Bedingungen erfüllt: 


- Unempfindlichkeit gegen Strukturveränderungen der zu übertragen- 
den Datenmengen, 


- Unempfindlichkeit gegen Veränderungen der Datendarstellung, 


- Möglichkeiten der Erweiterung/Einschränkung der über eine 
Teilmenge definierten Daten (Entitäten), 


- Möglichkeiten zur Speicherung vor einem Nutzerzugriff ge- 
schützter Systemsteuserdaten, 


- Ermöglichung einer datenunabhängigen Gestaltung der Datenver- 
arbeitungsfunktionen durch die Speicher- und Zugriffspfadunab- 
hängigkeit der Datenbereitstellung. 


Als Grundsatzlösung bietet sich dafür das nachfolgend definierte 
Modell eines virtuellen logischen Datensatzes an. 
Ein virtueller logischer Datensatz (VLD) wird definiert durch; 
(1) Ein VLD besteht aus m logischen Sätzen der Art A.J 

(j=21, 2, os., nm). 


(2) Jeder logische Satz der Art Ar] muß definiert genau 
(2a) einmal oder 
(2b) O oder einmal oder 
(2c) s-mal (s=0, 1, ..., t) 
im VLD auftreten. 


(3) Genau ein einmal auftretender Satz A.i ist als primärer 
VLD-Identifikator privilegiert. 


(4) Weitere Sätze A.k# A.i, die der Definition 2a genügen, kön- 
nen als sekundäre Identifikatoren auftreten. 


(5) Jeder Satz der Art A.j besteht aus n Worten W,w 
(w=1, 2, se, n). Die Anzahl w der Worte einer Satzart A.j 
ist tür alle s Sätze dieser Art konstant. 


(6) 
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Jedes Wort W.w besteht aus z Zeichen Z.y (y=l, 2, o.., X)» 
Die Zeichenanzahl z ist tür -Jjedes Wort W.m der Satzart 
AsJ konstant. 


Die Vereinigung der VLD zu einer Datei erfolgt über das Träger- 
medium des physischen Satzes (PD) gemäß der folgenden Defini- 
tionens 


(7) 


(7e) 


(7b) 
(7c) 


(8) 


Ein PD ist eine um implementierungsabhängige Spezifika er- 
gänzte Teilmenge des VLD mit variabler Zeichenanzahl, wobei 
gilt: 

Mi<=> [Sätze A.jEVLD:W.n(Setz A.J) # leorf 

(Menge der real mit Informationen belegten Sätze des VLD), 
PDvM ist eine Äquivalenzrelation in der Menge VLD. 

M=VLD ist möglich. M=0O ist auf Grund der Definition 3 unmög- 
lich. 


Eins Datei D ist die Menge aller PD eines Informationssy- 
etems (IS), die einen VLD-Typ zur Beschreibung des definier- 
ten Querschnittsproblems abbilden (z. B, Menge aller Ar- 
beitskräftedatensätze). D=fPD.xEIS:M.xEVLD} 


Zur Beschreibung der Anwendung von VLD seien folgende Organisa- 
tionsregeln aufgeführt: 


(9) 
(10) 


(11) 


(12) 


(13) 


(14) 


Jedes Wort W.w dient zur Speicherung einer Entität (entity). 


Zu jeder Entität existiert eine, Domäne (domaine), die den 
zulässigen Wertebereich syntaktisch und semantisch be- 
schreibt. Sind innerhalb eines Wertebereiches nur ausge- 
wählte Werte zulässig, erfolgt die Beschreibung in Form 
eines Schlüsselverzeichnisses. 


Die Worte W.w der gleichen Satzart A.j werden innerhalb der 
Datei D als gleichartige Entitäten gedeutet. 


Die Satzarten A.j sollten der entity-relationship-Methode 
entsprechend jeweils abhängige Informationsgruppen voll- 
ständig beschreiben, 


Die Satzarten A.j können organisatorisch als Pflicht- ‘(nach 
2a, 2c) oder Fakultativsatz (nach 2b, 2c) definiert werden. 


Die Beschreibung des VLD erfolgt in Form programmexterner 
Datenbeschreibungstabellen. 
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Die funktionale Einordnung des VLD in die Struktur der Computer 
Communication Software (vgl. /3/) ergibt sich als Schnittstelle 
‚zwischen dem CCS-Dateitransfersystem und für die Aufgabenklasse 
unifizierten CCS-Anwendungslösungen. 
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SEKTION 4 
Methoden und Werkzeuge zur Softwareherstellung 


Bauer, Günther 


Zun Einnatz_ von ISDOS bei dor Softwareherstellung 
1. ISD0OS - ein Workzeug zur Softnareherstellung 


ISDOS oteht für Information System Design und Optimization 
Syaten-Software, aloo zur Unterstützung von Entwurf und 
suocknäßigster Implementation von Informationssystenmen. 
Dieses Vorhaben reicht zurück bis ins Jahr 1968, als en 
dor Universität Mlohigan (USA) unter der Leitung von 

D. Teiochroew Untersuchungen zur Realisierung begonnen 
wurden. 

Seit 1972 sind die Komponenten PSL/PSA verfügbar. PSL- Pro- 
blem Statoment Language - int eine formale Sprache zur 
Beschreibung von Informationsverarbeitungssystenen. Als 
Grundlage wurde der Systenbegriff genählt, bei dem davon 
ausgegangen wird, daß ein System aus Elementen mit ent- 
sprechenden Eigenschaften und Beziehungen zwischen diesen 
Elementen besteht. Die Einengung dieses Systembegriffs auf 
Informationsverarbeitungssyateme führte zu einer Menge vor- 
gegebener Objekttypen, Eigenschafts- und Beziehungstypen. 
Darauf aufgebaut ist die Syntax von PSL. Der vorgesehene 
Anwendungsbereich ist die Spezifikation von Softwaresystemen. 
Verfügbar sind dafür B Systemaspekte, 22 Objekt- und 55 Be- 
gzlehungstypen. Die Systemaspekte der Spezifikation sind (vgl. 
geichroon 1977): 
Systemeingabe/-ausgabe, Systemstruktur, Datenstruktur, Daten- 
ableitung, Syotengröße und -volumen, Systemdynamik, Systen- 
eigonschaft, Projoktführung. 

PSA - Problen Statement Analyzer - dient zur Aufzeichnung der 
Spezifikation in einer Datenbasis und deren umfangreiche Ana- 
lyoo zum Zweck der Dokumentation des vorgeschlagenen Infor- 
nationsverarbeitungsbyatems. Die unterschiedlichen Ausgaben 
- hier Berichte genannt - lassen sich nach der Form und hin- 
sichtlich des Inhalts ordnen: 
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Br = 
Form Inhait 
. Listenfurmat e Datenbasismodirikation 
. Matrixtorn . Referanz-Ber.. 
. Grafik o Übersichts-Ber. 


. Analyse-Ber, 


Die Einordnung von PSL/PSA in die historische Entwicklung von 
Hilfsmitteln zur Herstellung von Software zeigt die Abbildung 1. 
Ein Teilthema innerhalb der Entwicklung von PSL war SODA - Syste 
Optimization and Design Algorithm (vgl. Couger 1982, S. 65 ff.). 
Es entstand dabei ein spezielles PSL, das die detailliertere 
Beschreibung der zu automatisierenden Prozesse ermöglicht. 

Mit SODA wird ein mehrstufiges Entscheidungsmodell realisiert. 
Dabei wird mittels SODA eine Menge von Hardwareressourcen aus- 
gewählt, es wird die Datenorganisation für die zu verwendenden 
Dateien bestimmt, und es wird die Menge der erforderlichen 
Verarbeitungsprogranne generiert (zum prinzipiellen Aufbau 

von SODA und seiner Wirkungsweise s.a. Herrlich und Linder 

1981, S. 143). Die historische Einordnung von SODA ist eben- 
falls im Bild 1 angedeutet. 

PSL/PSA wird auf höherer Stufe weiterentwickelt. Uber bereits 
vorhandene Nachfolgesysteme (SREM und PLEXYS) und sicher noch 
hinzukommende Entwicklungen wird weiterhin das Ziel verfolgt, 
alle Abschnitte der Softnareherstellung mit einem inte-. 
grierten Systen rechnergestützt ausführen zu können. Diese 
Zielstellung wird in Abbildung 1 mit System Design Optimizer 
hezeichnet und stimmt mit der für ISDOS überein. 
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2. PSL/PSA-Annendung bei der Softnareheratellung 


Ein Werkzeug ist ein "Arbeitsmittel zur unmittelbaren Bear- 

beitung eines Arbeitsgegenstandes (Roh-, Werkstoff, Workotüock)", 

Unnittelbare Bearbeitung steht hier für eine Einwirkung auf 

den Arbeitsgegenstand, so daß als Folge dieser eine Veründerung 

der Beschaffenheit des Roh- bzw. Werkstoffes oder eine Forn- 

änderung des Werkstücks eintritt. Mit dem Faktor Mittel zur 

Veränderung wird demzufolge das Wesentliche des Begriffe 

charakterisiert, 

Mit Softwarewerkzeug meinen wir ein Mittel zur Bearbeitung 

von Software, das selbst Software ist. Arbeitsgegenstand ist 

somit ein Ausgangs-, Zuischen- oder Endprodukt der Software- 

herstellung. Die Art des Arbeitsgegenstandes und die ausführ- 

-bare Funktion sind somit bestimmende Kennzeichen für ein 

Softwarewerkzeug. ! 

PSL ist, wie bereits ermähnt, ein Mittel zur Spezifikation 

von Softwareprodukten. Diese soll nach Möglichkeit vollständig, 

konsistent und eindeutig sein. Die Aufgaben von PSA sind die 

Analyse der eingegebenen Spezifikation und die Dokumentation 

jeweils geforderter Aspekte des beschriebenen Systems. Es 

werden dabei folgende Funktionen ausgeführt: 

- Zusammenstellung umfassender Daten- und Funktionsverzeich- 
nisse, 

- Durchführung einer statischen Netzwerkanalyse zur Sicherung 
der Vollständigkeit der abgeleiteten Beziehungen, j 

- Durchführung einer dynamischen Analyse zur Anzeige Born 
hängiger Beziehungen zwischen den Deten, 

- Analyse von Bedarfsspezifikationen (Systenmgröse, Ressourcen). 


Der Autor hatte Gelegenheit, im Rahmen einer Studie sich Über 
die wesentlichen Funktionen von PSL/PSA (Version 2.1) zu in- 
formieren. Die dabei gewonnenen Erkenntnisse lassen sich zu 
folgenden Aussagen und Meinungen zusammenfassen: 
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Die Sprache PSL ist wirklich einfach, Für die Notation einer 
einzelnen Anweisung genügt eigentlich das Wissen um die 
Schlüsselwörter für Objekt- und Beziehungstypen und zur 
Konvention über die Bildung von Bezeichnern (vgl. Balzert 
1981, S. 161). Die Regeln für die Zusammensetzung eines 
Problemstatements sind gleichermaßen einsichtig. 
Die Ablage des Problemstatements in der Datenbasis und die 
Mdifikationsmöglichkeiten ergeben sehr günstige Bedingungen 
für die Erarbeitung der Spezifikation. PSA akzeptiert 
syntaktisch richtige und mit dem bereits eingespeicherten 
Teil der Problembeschreibung verträgliche Erweiterungen. 
Dadurch wird in vorteilhafter Weise die schrittweise Ent- 
wicklung der Spezifikation unterstützt. Schrittweise kann 
dabei bedeuten: ; 
- die Verfeinerung der Spezifikation von oben nach unten, 
- das Sammeln von Angaben in der Reihenfolge der Gewinnung, 
- die arbeitsteilige Anfertigung der Spezifikation. 
Die mittels PSA erzeugbaren Berichte sind sehr vielfältig. 
Zur Unterstützung der spezifikationserarpeitung sind die 
Zusammenstellungen in Listen- und Matrixform wie Modifikation 
der Datenbasis, die Referenzberichte (Formatted Problem 
Statement, Dichonary) und die Analyseberichte (Data-Process- 
Interaction) sehr gut geeignet. Letzte weisen u.a. auf 
Lücken im Datenfluß bzw. auf unbenutzte Datenobjekte hin. 


Die grafischen Darstellungen, vorrangig zur Dokumentation ent- 
wickelt, sind nach Auffassung des Autors nicht in jedem Fall 
vorteilhaft. Die vorgegebene Größe der Druckerzeichen und 

die Blattaufteilung führen zu beträachtlichem Papierverbrauch 
und ziehen eine Grenze, die zu wenig Freiraum bietet. Für 

aie bildliche Darstellung der Prozeßstruktur läßt sich bei 
disziplinierter Verfeinerung auch eine gute Transparenz 
erreichen. Bei Datenstrukturen scheint diese Form jedoch 
völlig unzulänglich, 
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Zusammenfassend ist festzustellen, daß die Punktion, von 
PSL/PSA gut geeignet sind, die Ausarbeitung von Spezi- 
fikationen für automatisiorte Informationsverarbeitungs- 
“systeme zu unterstützen. Die Aufzeichnung der Eingaben in 
der Datenbasis konzentriert sämtliche Daten an einem Ort und 
bietet gute Möglichkeiten zur Modifikation. Die Funktionen 
des Umordnens und Formatierens schaffen die Voraussetzungen 
für die Darstellung verschiedener Aspekte des beschriebenen 
Systems. Damit werden die Kommunikation mit dem Auftraggeber 
einerseits und die Absprachen innerhalb der "Bearbeitergruppe" 
andererseits unterstützt. Die Prüfungen und Analysen der oin- 
gegebenen Daten in bezug auf Konsistenz, Eindeutigkeit und 
Vollständigkeit erhöhen spürbar die Qalität einer Systen- 
spezifikation. Fehler, die in der Anfangsphase der Software- 
herstellung verursacht und nicht erkannt werden, wirken an 
nachhaltigsten störend im gesamten Prozeß. Ein großer Teil 
dieser Fehler wird durch diese Prüfungen ausgeschlossen. Der 
Einsatz und die weiterführenden Arbeiten zu PSL/PSA sonio 

zu 50VA sind als Bestatigung für die Praktikabilitat den 
eingeschiagenen Weges anzusehen. 
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Kurzfassung des Vortrages für bit!85 


Autor: Gunter Chmiel 


Titel: Perspektiven der Entwicklung und Anwendung des 
Technologischen Systems zur Softwarentwicklung TESYS 


Ex 


Ausgehend vom gegemwärtigen Stand bei der Bereitstellung tech- 
nologischer Systeme zur Softwarentwicklung und ersten Anwender- 
erfahrungen wird in einem ersten Schwerpunkt dargelegt, welche 
funktionellen Erweiterungen und Kopplungskomponenten zwischen 
TESYS und anderen Systemen (PORG, PSU, DBS/R) in unmittelbar 
ne net verfügbar sein werden. Diese werden inhaltlich 
erläutert, ı x 


Der zweite Schwerpunkt beschäftigt sich mit der \leiterentwick- 
lung des TESYS:.im Zeitraum bis 1987 und später sowie die sich 
daraus ergebenden Perspektiven der Anwendung, besonders unter 
den spezifischen Bedingungen der DDR, 


Die Weiterentwicklung von TESYS besteht vor allem in der Unter- 
stützung zusätzlicher 


-Methoden (vor allem der Entwurfsphase), 
-Zielsprachen und 


‚-Zielmaschinen (Portabilität für ESER, K 1600 unter MUTOS, 
ACS-großes Modell) 


mit dem Ziel, einen Beltrag zur Schaffung einer einheitlichen 
Projektierungsumgebung für Anwendungssoftware zu liefern, 


4 
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Detering, Rolf; Herrlich, Ottomar; Kühle, Frank; 
Lorenz, Manfred; Protzner, Sven 


Entrurf für komplexe Steuerungssysteme - 
RESEM-Anwenduns für Mikroreohner-Stellwerk 


1. Einleitung 


Durch den Einsatz von Computern zur Bearbeitung immer komplexer 
werdender Auf&aben wachsen Bedeutung und Einsatzmöslichkeiten 
zum reohnersestützten Soft- und Hardware — Entwurf, In der Ver- 
Sansonheit wurden Unterstützungen für Entwurfsprozesse fast 
aussohließlioh auf proßrammiersprachliohen Niveau anBoboten. 
Der enorme Einfluß davor l11oßender, früher Phasen auf Qualität 
und Kosten des Finalprodukts maohen aber eine Unterstützung 
dieser Phasen dringend notwendiß. Dabei ist es wiohtig, eine 
durohßänsiße Entwurfstechnoloßie zu sohaffen, die bis hin zur 
Implementierung Unterstützung bietet. An eine derartige Tech- 
nolo&i1e werden sehr hohe Anforderungen Sestellt, die besonders 
eine starke Flexibilität betreffen. Operationen und Bescohrei- 
bunssmittel müssen so Seartet sein, daß mit ihrer Hilfe der Be- 
sante Entwurfsprozeß unterstützt worden kann, 


Bei der Betrachtung früher Phasen wirä os besonders deutlich, 
daß eine funktionelle Aufteilung der Entwurfskomponenten auf 
Soft- oder Hardware nooh nioht Brundsätzlioh vor&enormen werden 
kann. Dahor Belten die zu zeigenden Möglichkeiten allgemein für 
den Entwurf von Problemlösungen; des besseren Vorständnisses 
wegen werden sie an Software-Beispielen erläutert. 


Die praktisohe Umsetzung der Bowonnenen Erkenntnisse wird mit 
Hilfe der Reohner&estützten Software — Entwurfsmothode (RESEN) 
vor&enommen,. Die Anwendunß für die Praxis erfolgt für eine kon- 
plexe, sicherheitsrelevante Entwurfsaufßgabe - die Steuerung 
eines Stellwerks, 

Der Einsatz von Rechenteohnik zur Steuerung von Btellwerken bo- 
deutet einen völligen Generationswechsel von dor bisher inter- 
national eingesetzten Relais-Teohnik zum Einsatz der Mikroolok- 
tronik, 


2. Zielsetzung 
Die auf dem Entwurfssektor Benerell auftretenden Probleme bei 
dor Beherrsohunß komplexer Systeme zeißen sich auf Grund der er- 
höhten Anforderungen verschärft für sicoherheitsrelsvante Anwen- 
dungen. Der zu führende Sioherheitsnachweis erfordert sohon 
frühzeitig Festlegungen zur Systematik des Entwurfsprozesses 
und der dabei einzuhaltenden Qualitätskennzeichen. Diese Fost® 
lo&ßungen müssen in Abstirmung aller am Entwurf beteiligten Per 
sonensruppen der untersohledlichen Teilgoblete von Auftraßßeber, 
Entwioklor und Nutzer Betroffen werden. Alle während der Pro- 
blemlösungs notwendigen Operationen müssen als inteßrale Bestand- 
teile des Entwurfsprozesses aufgefaßt werden. Als wesentliohste. 
Operationstypen betrifft das die Operationen zur 

Konstruktion (K) 

Modifikation (M) 

Prüfungs (P) und 

Dokumentation (D). 
Daraus können modulare Entwurfsteohnoloßien zur Nutzung für 
versohledenste Einsatzbereiche aufßebaut werden. Dabei können 
allgemeine Folgeabhängiskelten zwischen den Operationstypen 
ausßenutzt worden, 


Bo Eilt z.B. für Modifikationsoporationen, daß sowohl die Kodi- 
fikationen als auch die daraus fol&enden Prüfungen dokumentiert 
werden müssen. | 


Als Geßenstand für alle Operationen im Entwurfsprozeß muB eine 

einheitliche Wissensbasis vorhanden sein, die zu Jeden konkre- 

ten Zeitpunkt den aktuellen Zustand des Systens, also der Ent- 

wurfseinheiten und ihrer Beziehungen zueinander, widerspießelt. 
Für alle Operationen &ilt, daß sie für den Einsatz auch in frü- 
hen Entwurfsphasen auch .dio Eißenschaften der frühen Fhasen bo- 
rüoksichtisen müssen, ohne Erundsktzlich nur für diese Phasen 
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nutzbar zu sein. Hier sind vor allen als Charakteristika zu 
nennen: 
- noch viele Unklarheiten 
- unvollständißo Beschreibungen 
- inhonoßener Bearbeiterkreis 
- hohe Komplexität, 


Daraus fol&ßt z.B., daß Prüfungen auoh dann vor&Bonommon worden 
können, wenn bestimmte Beschreibun&sstufen noch nicht ab&o- 
schlossen sind. Alles vorhandene Wissen, unabhängig von seiner 
Ab&Seschlossenheit, muß schon Üüborprüfbar soin. Damit können 
Prüfoperationen z.B, auch Hinweise auf zu korplettlorendo Btol- 
lon des Entwurfon Sebon, 


3. Theoretische Grundlagen 

Für die Durohführung eines Entwurfsprozossos orgibt sich dio 
Hotwendiskoit, Entwurfsschritto ontsprechend don mößlichen. Ope- 
rationen zu definieren. Dabei finden Srundsätsliohe sonie 5po- 
zielle Erfahrungen des Einsatz&ebietos für die Aufstellung von 
Problemlösungen ihren Kiederschleß. Dio Abstimmung der Kommu- 
nikationsschnittstelle für die an Entwurf beteiligten Porsonen 
bedinst eine hoho Flexibilität für Beschreibunssmittel und 

- Methoden. Daher muß der die Informationen über den Entwurfs-. 
prozeß enthaltenden Wissensbasis sehr hohe Aufmerksamkeit Go- 
schenkt werden, da sie diese Flexibilität Bewährleisten muß, 
Auf Grund der Eißenschaften früher Phasen er&ßeben sich Proble- 
so bei der Formalisierbarkeit der Beschreibunssmittel als not“ 
wendige Voraussetzung für die Reohnerstützung. Besondoro für 
.Komploxo Entwurfsaufßaben wird eine standardisierto Vorßehens- 
weise mit entsprechenden Beschreibunssmitteln anßestrebt. Dio- 
sos Problem kann nicht durch feste Entwurfssprachen Belöst wer- 
don, da dabei besonders die Ausdruocksmöglichkeiten für unklare 
bzw. unvollständiße Sachverhalte nicht Geßeben, wären. Dazu sind 
Problemlösungen als anwendunßsangepaßto Hodello zu beschreiben, 
Das setzt Ausdruoksmittel in der Art Bonerierbarer Faohspra- 
ohen voraus, die aber während des Entwurfsprozesses varilorbar 
sein müssen. Durch die modellhaftoe Formullorung der späteren 
Lösurß sind Untersuchungen am Hodell schon lange vor der Roali= 
sierung der Lösung am Zielsysten möglich, 


r 
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‚Da sioh dio Beschreibungszittel nicht in sinnvoller Weise als 
fosto Entwurfssprache formallsieren lassen, wurden die Defini- 
tlonsnößlichkeiten für Besohreibungssmittel formalisiert. Danit 
ist die Anpassung an eine beliebige Sprachwelt dor Rutzeruerse- 
bung durchführbar. 


Bei einer solohen Vor&ehensweise er&eben sich Vorteilos 
- Rechnorstützung ist mößlich, 
- Universalität im Rahnen der Definitionsmöglichkeiten, 
- hohe Variabilität/Floxibilität/Anpassbarkeit, 


Für die durchgängige Unterstützung des Entwurfsprozesses muB ei- 
ne Violzahl von Problonen Gelöst werden, wobei im wesentlichen 
Erkenntnisse aus drei Wissonschaftsdisziplinen Benutzt werden 
könnens | 

- Datonbanken, 

- künstliche Intollißons und 

- Softwaro-Toohnologio. 


Für die Or&anisation der Wissonsbasis als einos der Kernstücko 
einon ontwurfsunterstützonden Systems sind besonders Erfahrungen 
aus den Bereichen Datenbanken und künstliche Intelligenz relo- 
vant. Sowohl von Selten der Nutzorakzeptans als auch der prak-= 
tisohen Roalisierbarkeit besitzen relational or&anisierto Daten- 
bason Eroßo Vorteile. Daher wurde für RESEN eine Definitionsbasin 
auf der Grundlage einos Entity/Rolationship - Ansatzes Sewählt, 


4. -Hodellansatz in RESEM 


Die Bearbeitung einer Entwurfsaufßabe entspricht dann der Auf- 
stollung eines Entity/Relationship - Modolls der Sewünschten Lö- 
‚sung. Als Entitäten troten allo Objekte des Entwurfsmodells in 
Ersoheinung, z.B. Funktionen, Daten, Systene, Bearbeiter, Zeiton 
usw. Also Rolationon worden alle Beziehungen zwischen Objekten 
dos Entwurfsmodolls boschrioben, z.B. Bteuorflußboziehungen, D8> 
tonflußbezichurson, Hierarchioboziehungen. 
Dio Hutzuns von Rolationen kann ohne Verlust an AllSeneingültis- 
koit ouf binäro Relationen 

R<SVx MO mit V > Vorbereich 


H 2 MNachbereich 


oln&oschränkt werden, 
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Im Entwurfsprozeß werden zwei Stufen der Modellbilduns unter- 


sohileden. 


401% Definition der Beschreibungsmittel (Rahmennmodell) 


Definition der Objekttypen OBJTIP 
Sie umfassen Klassen Sleichartißer Objekto >0O, Btufo, d.he 
ein OTw e OBJTYP 
kann für eine Relation RBEII als auch 
als RE c 0Ww x N) 
in Ersoheinuns treten, 
ZeBo FKT für Funktionen 
DAT für Daten 
OBITYP = fOM, 072, ..., Ola} 


« Definition der Merkmalstypen METYP 
Sie enthalten Klassen &lelohartiger Objekte = O0, Btufe,. 
d.h. ein MPx € NKTYP 
kann für eine Relation MKERj nur als 
KR) <c 0 x Mix 
in Erscheinung treten, 
' 2zeB. Zeit für zeitliche AnSaben. 
METYP = MM, MID, ..., Mix | 


e Definition der Relationen mit V, B € OBJTYP 
Sie beschreiben Beziehungen zwischen Objekten > 0, Stufe, d.h, 
solohe Objekte, die wiederum beschrieben werden können, 
BEI <Z 0Tk x Op 
z.B. Hierarchiebeziehung 
BESTEHT_AUS < FKT x FKT 
RELATION = {REL1, REL2, ..., REiy} 


e Definition der Relationen mit V E OBJTYP und 
& N e WMKTYP 
Sie ordnen Objekten > 0. Stufe Merkmalsgrößen zu, d.h. 
Objekte = O0, Stufe, 
MERJ < Olr x MTs 
zeBo ABSCHIUSSTEBEMIN = FET x ZEIR 
MKREL = $ MKR1, MER2, oo., MERZ } 


Die Steusrflußbeschreibung über Relationen wird für komplexo 
Entscheldunsssituationen sehr aufwendiß und unübersichtlich, 
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"daher worden hior Entscheidunsstabellen eingosetzt. Durch die 
Einschränkung auf Tabollon des einfachen Typs mit Eintreffer - 
Eißonschaft und der eusschließlichen Angabe von Ende (E) und 
nächster Takt (n.T.) in der Verbundaktion wird Generell ein 
wohlstrukturiortoer Steuerfluß Bewährleistet. Außorden worden 
damit Sute Analysevoraussetzungen bz&l. Vollständißkelt, Wider- 
spruochsfreiheit und Redundanz Seschaffen. Im Aktionsteil kön- 
nen zur Anßabe von Boquonzen bzw, Parallelitäten Ordinalzahlen 
je Reßel an&ße&ßoben werden; Bleichos Bilt für Wertezuwelsunssak- 
tionen im Informationsteil. 


Die methodischen Erkenntnisse aus der Softwarsteohnologie las- 
sen sioh dann durch Vorgabe einen bostimnten Beschreibungsun- 
fen&es des Rahrienmodells umsetzen. Dieser Beschreibungsumfans 
kann entsprechend der zugrunde Selesten Hothodik des Entwurfs- 
prozesses schrittweise erweitert bzw. modifiziert werden. Mit 
Hilfe der Grundopsrationen und der Beschreibungsnmittel des Ent- 
wurfsmodells lasson sioh Sahrittfolgen festlegen, die der Um- 
setzung einer Entwurfsteohnoloßi1e entsprechen, 


4,2. Nutzung der Besohreibunssmittel (Rutzermodell) 


Eier wird das konkrete Nutzerproblen beschrieben, in den die 
Entitäts-Tupel entsprechend den definierten Relationen anseßo- 
ben werden. i 

ZeBe FKET A BESTEHT AUS A1, A2 
bedeutet, daß die Relation BESTEHT AUS um dio Tupel (A, A1), 
(A, A2) erweitert wird. 
Außer den Konstruktionsoperationen für Rahmen- und Nutsermodell 
sollen nooh Prüfoperationen vor&estellt werden. 


All&Semein müssen dieso es erlauben, loßische Ausdrücke mit Bo- 
zußnahme auf die Wissensbasis des Entwurfssystens zu formulio- 
ren. In RESEM werden prädikatoenloßische Ausdrücke der 1. Btufo 
mit den logisohen Operatoren UND, ODER, HICHT, IHPL, AEQU und 
den Quantoren EXIST, FORALL verwendet, Die Bezußnahme auf dio 
RESEN - Wissensbasis wird über das Standardprädikat ASSO0 (d.h! 
Assoziation zum Wissen) realisiert, das über Eleiche AnBabends- 
lichkeiten wie bei Konstruktionsoperationen vorfüßt. it Hilfe 
dieser Ausdrücke können Aussaßeform - Verbindungen (GILT) oder 
Kennzeiohnungsforn - Verbindungen (SUCHE * ALLE) Boebildet wor- 
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den, in denen Variable der Grundbereiche OBJTYP, MKTYP, 
RELATION, MKREL sowie Objekte auftreten könnens 
ZeB. (GILT (OBJEKT OB1) als Variable 
(UND (ASSO FKT OB1 BESTEHT_AUS A1) 
(ASSO FKT OB1 BESTEHT_AUS A2))) 
Er&ebniss true 


5. Entwurfssohritte 


Besonders 'deutlioh tritt die Notwendigkeit einer durohgängigen 
Entwurfsnethode auf dem Gebiet der sicherheitsrelevanten Pro- 
zeß - Steuerung zu Tage. Hier wird RESEN in der Praxis zur Mo- 
dellieruns der Steuerung oines Stellwerks auf Rechner — Basis 
einsosetzt. Die andeführten Entwurfssohritte stellen somit auch 
eine Senissoe Rückkoppluns der Erfahrungen bei der Bearbeitung 
der Entwurfsaufßebe dar. 

Die Modellarbeit wurde als Kernstück in folgenden Gesantent- 
wurfsablauf eingebettet: 


8.1, Zielfestleßung, Aufgabenstellung 
S.2 Analyse und Modellbildung das Basissystens 
8.30 \ Analyse des Sewünschten Systemverhaltens; 


nthese und Überprüfung des Steuersystens 
8.301. efinition des Rahmenmodells 
Bo3020 efinition des Nutzermodells 
8030201, Entwurf durch sohrittweise Verfeinerurs 
3.3.2.2./ Überprüfung ohne Eohtzeiteigensohaften 
8.303. ° Ableitung und Untersuchungs des Stoeuernetzes 
8.3.4.  Bohtzeituntersuchungen 


Bote Vollständige Al&Sorithmierung, Realisierunsskonzeption 
Be5° Kodierung für Zielreohner 

B.6% Tostung der Realisierung 

8.70 Installation, Inbetriebnahne 

8.8, Wartung und Pflego 


Eg folgen einißo ausgewählto Bemerkunson zu typisohen Mutzurfs- 
sohritten. 
8,1. Zielfestlegung 
1. Charakteristika für das Mikroreohner-Stellwerks 
- Umfangreiche Problematik (für größeren Bahnhof bisher oa. 
25000 Relais mit 150000 Kontakten ) 
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- Hohe Sichorheitsverantwortung (wenißer als eine Befährdete 
Sißnalzußfahrt auf 1010 Signaläugfahrten zugelassen, deshalb 
auch hoohßradiß fehlerfreie Software nötiE&) 

- Volkswirtschaftlioh bedeutsane Auf&abe 

- Lanse Lebensdauer (normative Hutzundsdauer oa. 30 Jehre; kein 
eßwerfprojokt", Generationswechsel bei Rechentechnik ein- 
kalkulieren). 


2. Das zugehörige Basissysten, dee das Steuerobjekt, enthält 
als Außenanlagen z.B. folgende Basiselemente (Zahlen für 
&rößeren Bahnhof )s 150 Weiohen, 180 Signale, 150 Isollerab- 
schnitte, 15 Streokenblook-Gleise, 3 Weßüberßangssiocherungs- 
anlaßen usw. Da die Außenanlaßen von bisherißer Technik übor- 
nommen werden, wird im folßenden der Entwioklungsschritt S.2, 
nicht betrachtet, 


8.3. Analyso des Bewünschten Systemverhaltene, 


Synthese und Überprüfung des Steuersystens 


8.3.1. Definition des nutzerspezifischen Rahmenmodells 
Es sind die Bescohreibunsselemente (Objekttypen, Relationen) 


festzulegen. Für das Mikrorechner-Stellwerk wurden definiert 
(Aussohnitt)s 
 OBITYP = [FRE DAT... | 
RELATION = fBESTEHT_AUS, o.., SENDET |} 
BESTEHT AUB C FER x FET U 
DAT x DAR 

SEHDET <e PER x Dat 

USW. 


823.2. Fntwioklunß des Hutzermodells 
8.3.2.1, Entwurf durch schrittweise Verfeinerung und funktionel- 
le Dokumantation 


sohritte durohzuführen; die ersten drei betreffen die Funktionen 
(Aktionen), weitere drei betreffen die logischen Daten (Informa- 
tionen). 
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4. Hierarchie für Funktionen bilden 


Die Graphik zeigt oine Stello der zu 


E 
7 Nur entwerfonden Funktionen als Hiorar- 
8 W K B 


ohle-Strukturs Die zußehörige RESEI- 


sel. Sprachforn (für dio Eingabe In den 
WG WE 


WK WD Roohner) lautet bei der Boschroibung 
der Funktion Weiche Ws 


FKT W ENTHALTEN_IN E 

FKT W BESTEHT_AUS WE, WK, WD, WG 

Die erste Zeile dieser Sprachforn drückt dio Einordnung in dio 
nächst höhere Hiorarshioebene aus, dio zweite Zeile bosohreibt 
dio Unter&liedorung in dio nächst niedero Ebene. 


2. Problenbedinsten Steuerfluß besohroiben 
Das heißt: Wie sind die zu einer Unter&liederung Behöreonden Funke 


tionen miteinander vorknüpft? Das Beschreiben Boschileht in Eut- 
scheidunsstabellon. Bio sind bei RESEH so reSlonmontiert, daß 
Wohistrukturiertheit entsteht: Zußelasson sind nur dio Verknüp- 
fun&en Sequenz, Alternativo (einschließlich Caso-Struktur), Zyk- 
lus und Parallelität, ferner Unabhängiskeilt. Als Vorbundaktion Va 
sind nur zugelassen Ende (E) und nächstor Takt (HT), kein GS0TO. 
Es müssen Eintreffor-Eutscheidunsstabellon seins Zu jeden Zeit- 
punkt trifft nur eine Spalto zu (außer ELSE). Ein Beispiel folst 
en Endo des Aufsatzes, 


3s Evontuoll nutsorspezifisohe AnBaben für Funktionen notieren 
Zum Beispiel Synohrenisationsrolationen, Zeitforderunsen oder Zu- 


ordnung zu den verschiedenen Teilsyastersn duroh die Relation 
GEHOERT_ZU, 


4, Hierarchie für Daten bilden 
Das Beschieht analog zu der Hierarohiobildung für Funktionen. 


DWE RESEN-Sprachforn: 
9 en EEE 
wir DWEr DAT DWEV ENTHALTEN_IN DWE 


NS | DAT DWEV BESTEHT_AUS DWEV.A, 
DWEVA DWET_B DWEVFDWET_B, DWET_F 
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5, Datenfluß beschreiben 
Zum Beispiel lautot dor Datonfluß in BESEN-Sprachforn aus der 
Sicht dor Funktion WER: 
PET WER EUPPARHOT DWEV_A, DWEV_B, DWEV_F 
FKT WER SENDET DWEV_F. 
An anderor Stelle wird dor Datenfluß aus der Sioht dor Daten bo- 
sohriebon, um allo An&aben doppelt zu haben - als Umkehr-Rela- 
tion. Das entspricht den in der Sicherunsstechnik Bern benutzten 
Verdopplunsen aus Sicherheitsgründen. 


6, Eventuell nutzerspezifische Angaben für Daten nennen 


Zum Beispiol Zuordnung eines Datums zu versohiedonen Teilsysto- 
nen durch die Relationen GEBILIET_IH und BENORTIGT_VON. 


Entsprechend diesen sochs Teilschritten vollzieht sich der Ent- 
wur? für jodes Problomseßnent von der obersten bis zur untersten 
Ebene. Daboi können viele Entwurfsbearbeiter parallel arbeiten, 


Mikroreohner-Stollwork 
ug 
0 E_ nn 0 
8 u K B ... 
vs WE WE WW _ 
WEB WER WEI WEH 
WESE WESV WESR WEIP WEIZ WEIN 
Bra nn. 
WEBV_A ge WESV_Z 
WESV_BA WESV_BS WESV_EH WESV_BR 
er E 
WESV_BHE WESV_EHF 


Die Graphik zeißt in Baunform acht Hierarchisebenen. Dabei wurde 
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stets nur ein Zwei weiter verfeinert; auch die Übrigen Zweißeo 
besitzen (nicht dargestellt) weitere Unter&liederungen. 

Die sinnvolle Hierarohiebildung ist ein sohöpferischer Vor&ang 
mit Freiheitssraden, Es wurden schon verschiedene Varianten der 
Hierarohiesbildung untersucht. Hat man eine Hierarchio entworfen, 
so er&ibt sich der Steuer- und Datenfluß dann meist folgerichtig 
entspreohend den stellwerkstypischen Aufßaben. 


o)_Detailbeispiel für ein Funktionssesment_einer unteren _Hier-_ 


Nach der Überschrift folgen in RESEN-Spraochform die relationalen 
Ansaben 
- zur Hierarchie (ENTHALTEN_IN und BESTEHT_AUB) 
- zum Datenfluß (ENPFAENGT und SENDET; die Kurzform aller Daten 
beginnt mit D). 
Voren steht jeweils die Kurzform, danach die Lanßforn. 


Weiter unten ist die Entscheidunsstabello auszußsweise darso- 
stellts ; 

Im Aktionsteil ist neu, daß jo Reßol Bequenzen durch fortlaufende, 
Parallelitäten duroh &leiche Ordnun&szahlen ausßedrückt werden. 
Den letzten Teil der Entscoheidunsstabelle bildet‘ der Informations- 
teil. Dieser wurde neu aufßenommen, um mögliche Wertzuweisungen 
für Variable ausdrücken zu können. 


Insgesamt beinhaltet RESEM sowohl die Methode des Vorgehens (6 
Teilschritte 8emäß a)) als auch die Bereitstellung der Beschrei- 
bun&smittel (RESEN-Spraohform und -Entscoheidungstabellen). 


8.3.2.2. Überprüfung ohne Eohtzeiteißenschaften ' 
Naohdem - wie beschrieben - der Entwurf duroh den Menschen er- 


fol&te, schließen sioh rechnersestützte Überprüfungen an. Dazu 
Sehörens 


- Prüfund auf definierte Syntax Semäß Rahmenniodell, 


- Prüfung auf Ioßik des Entwurfes Gemäß beschriebenen Relationen 
auf Widerspruchsfreiheit, Vollständißkeit usw, 
Beispiels. 
(SUCHEXALLE 10 (OBJEKT OB OBJTYP OF) 
(NICHT _ 


(EXIST (OBJEKT 0B1) Förks, übernächste Seite 


WESV_BHEH FKd WESV_EER_RAUPTFAHRTELEMENT 
ENTHALTEN_:IN: WESV_EHE FET_WESV_B_EINZELHILFSAUFLOESUNG 
BESTEHT_AUS : OEDZ_2 FET_OEDZ_2_MINUTEN 
e OMT' FKT_OM_INFORMTEIL_'VERARBEITUNG 
WESV_EHEH_D FKT_WESV_BHEH_DV_AUFLOESEN 
WESV_EHEH_Q FET_WESV_BHEH_QV_AUFLOESEN 
WESV_EHEH_ A FET_WESV_BHEH_MITAUFLOESUNG 
OF’ FKT_O_FEHLERBEHANDLUNG 
EMPFAENGT s DEZV_E DEZV_ELEMENTRZEIGER 
DWEV_FVFI DWEV_FVF_SPIZ 
DWEV_EVFL_ DWEV_FVE_LINKS 
DWEV_FAQS DWEV_FAQ_SPITZE 
..o ” 
SENDET s DWEV_FVFI_ DWEV_FVF_SPITZ 
 DWEV_FVEL DWEV_FVF_LINKS 


WESV_BHEH AB Oo... ELSE 


DEZV_E . DWEV_FVFI = "VERSCHLOSSEN LLL 
DEZV_E . DWEV_FVFL = "VERSCHLOSSEN oO LO - 
DEZV_E . DWEV_FAQS = "ANGEREGT LOoo0 


OEDZ_2 1114 - 
OMI 222 - 
WESV_BHEH_D a 2 
WESV_EHEH_Q 2 - - - 
WESV_EHEH_A 333 - 
OF -.. q 
VA EEE E 


DEZV_E . DWEV_FVFI := 'UNVERBSCHLOSSEN 1141 
DEZV_E . DWEV_FVEL s= 'UNVERSCHLOSSEN - 1- - 


(ODER (ASSO on OB BESTEAT_AUB 0B1) 
(ABSO OT OB SENDET 081))))) 
Es sollen (max. 10) Objekte mit den zugehörigen Objekttypen Be- 
sucht werden, für die weder Hierarohiobeziehunsen entsprechend 
BESTEHT_AUS nooh Datenflußbeziehungen entspr. SENDET angegeben 
wurden. Damit können also Stellen im Entwurf Befunden werden, 
die bezüßlioh disser Beziehunsen unvollständiß sind und nooh wei=- 
ter bearbeitet werden müssen; dies würde z.B, festgestellt für 
FKT WE. 


- Funktionelle Ablauftests 
(Überprüfung auf funktionelle Richtigkeit, 
Testuns des Zusammensplels zwischen Steuer- und Basissysten 
vor Programmierung /Implenmentierung). / 


Spätere Entwurfesohritte (ab 8.3.3.) enthalten Netzuntersuchungen, 
Echtzeituntersuchungen usw, 


Entwioklun®sstand 

RESEM wird in der Praxis für das vorgestellte Entwurfsbeispiel 
anSewendet, Die Rechnerstützung der Entwurfsmethode RESEN ist 
implementiert als Experimentalsysten auf Basis der Sprache LISP 
(TULISP für ESER). 

Die Betreuung der RESEN-Anwendung erfolgt durch eine Systement- 
wloklun&s&ruppe - sowohl bezüßlioch der Beschreibunssmittel als 
auch der Entwurfsnethodik,. Dazu werden Nutzerhinmweise erarbeitet 
und Seminaro durohßeführt, 
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Unterstützung von Modellentwicklungsarbeiten durch das 
Dialog-Programmsystem NOVAS 


1. Einführende Bemerkungen 
Die Entwicklung von Modellen erfolgt in mehreren Arbeits- 


stufen. Dabei treten neben Problemen, die eine tkeoretische 
Arbeitsweise erfordern, auch solche auf, die mit einem 

mehr oder weniger großen numerischen Aufwand verbunden 
sind. Das betrifft häufig Optimierungsrechnungen (zum Zweck 
der Parameteranpassung). Daneben ergibt sich die Notwen- 
digkeit, mit dem Modell eine Reihe von Simulationsexperi- 
menten durchzuführen, deren Ergebnisse anschließend ausge- 
wertet werden müssen. Dabei kann es sich beispielsweise um 
Monte-Carlo-Simulationen handeln. Eine andere Aufgabe wäre. 
die Untersuchung der Parametersensitivität des Modells, 
d.h. die Feststellung, welchen Einfluß die einzelnen 
Modellparameter auf die Modellergebnisse haben. Häufig 
erweist sich auch eine umfangreiche Datenanalyse als not- 
wendig. In allen Fällen ergibt sich meist ein beträchtlicher 
numerischer Aufwand. Es müssen deshalb Computer zu Hilfe 
‘genommen werden. Dabei ist es günstig, die Arbeit mit dem 
Modell und die Auswertung der Ergebnisse variabel zu gestal- 
ten, da es häufig erst nach einer Teilauswertung möglich 
wird, Entscheidungen über weitere Arbeitsschritte zu fällen. 
Deshalb erweist sich ein allgemeiner, dialogfähiger und 
modellunabhängiger Testrahmen. für Modellvalidierungsarbeiten 
als ein gutes Hilfsmittel. 

Ein diesem Ziel entsprechendes Konzept wurde mit dem 
Programmsystem MOVAS entworfen. Anhand der Teile SENSIT 
(Sensitivitätsanalyse) und. MODAW (Auswertealgorithmen) sol- 
len einige Aspekte dieses Systens vorgestellt werden. 


2. Allgemeine Charakteristik des Systems 
Das MOVAS-System besteht aus einer Reihe von FORTRAN- 


Programmen. Es arbeitet im Dialog unter TSO-Bedingungen. 
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Dabei werden berechnete Ergebnisse stets auf dem Bildschirm 
angezeigt. Der Nutzer kann dann entscheiden, ob sie zusätz- 
lich gedruckt bzw. in eine Ergebnisdatel ausgegeben werden 
sollen. 

MOVAS ist nicht an ein bestimmtes Modellkonzept gebunden. 
Es sind lediglich eine Reihe von Koppelbedingungen zwischen 
den das Modell repräsentierenden Programmen und den Verarbei- 
tungsprogrammen zu erfüllen. Die Kopplung wird dann mit Hilfe 
einiger normierter Unterprogramme vorgenommen. Diese Progran-, 
me realisieren die modellspezifischen Eingabeoperationen, 
das Ausführen der Modellrechnungen, das Sichern und Wieder- 
herstellen des Modellausgangszustands sowie Bezugnahmen 
zwischen Modellgrößen und Verarbeitungsprogrammen. Die Para- 
metervermittlung erfolgt dabei mit Hilfe von COMMON-Blöcken. 

Die Erstellung der Koppelprogramme wird durch ein zum 
System gehöriges Hilfsprogramm unterstützt. Es konstruiert 
mit Hilfe eines Dialogs mit dem Nutzer einen FORTRAN-Quell- 
text, der dem Standard der Schnittstellen entspricht. 

Die Bezugnahmen auf die Modellgrößen erfolgt während der 
Arbeit mit dem System durch vom Nutzer selbst festzulegende 
Bezeichnungen. j 


3. Arbeitsweise des Teilsystems SENSIT 
Für die Sensitivitätsanalyse eines liodells werden die 


Modellergebnisse, berechnet für verschiedene variierte Para- 
meterwerte, benutzt. Aus diesen Ergebnissen. werden weiter- 
gehende Kennwerte hergeleitet, die dann durch MODAW unter- 
sucht werden können. Diese Kennwerte repräsentieren den Ver- 
lauf der Modelltrajektorie für die verschiedenen Parameter- 
werte, die Ableitung der Modelltrajektorie nach den Parametern 
des Modells, die relativen Änderungen der Modelltrajektorie 
bei Parametervarieationen und das Verhältnis zwischen den 
relativen Änderungen der Modelltrajektorie und der Nodell- 
parameter. 

Es gibt 2 generelle Möglichkeiten, die Ergebnisse der 
Sensitivitätsanalyse auszuwerten. Die erste Möglichkeit be- 
steht nach der Erzeugung der Modellergebnisse. In diesem 


Fall kann aber nur auf die Ersonläns einer Paramstervariation, 
nämlich der zuletzt durchgeführten, zurückgegriffen werden. 

Das wird 1.a. nur für eine erste Auswertung hinreichend sein. 
Günstiger ist es, die berechneten Ergebnisse in Zwischendateien 
auszugeben. Mit Hilfe eines speziellen Programms des WOVAS- 
Systems können diese Dateien dann beliebig gemischt werden. 
Dabei können denn die Modellergebnisse verschiedenster Parameter- 
variationen ausgewertet werden. 


4. Das Teilsystem MODAW 
Die bereitgestellten Modellergebnisse werden an Hand von 


Parameterfeldern an MODAW übergeben. Die Vermittlung von 

Strukturparametern für dieses Teilsystem erfolgt durch COMKON- 

Blöcke. Zur Auswertung von Modellergebnisgrößen können folgende 

statistische Prozeduren gewählt werden : 

- Tabellierung 

- Grafische Darstellung 

- Berechnung statistischer Maßzahlen 

- Berechnung der Matrix der Korrelations- und Autokorrelations- 
koeffizienten mit beliebiger Verschiebung 

- Klasseneinteilung, Häufigkeitsanalyse mit Histogrammausgabe 

- Chi-Quadrat-Anpassungstets auf Normal-,Exponential-,Gleich-, 
Poisson- und Binomialverteilung 

- Ausreißertest 

Vor der Durchführung dieser Prozeduren können die Schrittweite, 

der Zahlenbereich und der Umfang beliebig festgelegt werden, 

mit denen dann die Auswertung erfolgt. Für mit Datum versehene - 

Modellergebnisse kann die Auswertung nach Monaten und Dekaden 

aufgeschlüsselt erfolgen. Das System arbeitet in mehreren Zyklen, 

die die Wiederholung einer Prozedur oder eines Teilsystems 

ermöglichen. Auf Abb. 1 ist die Zyklusarbeit von MODAW schema- 

tisch dargestellt. 


Dipl.-Math. Peter Döring 

Dr. rer. nat. An Thu lassig 

AdL der DDR 

Inst, f. Landwirtsch. Information 
und Dokumentation 

1086 Berlin ,„ PSF 1295 
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Festlegung der für die 
Auswertung benötigten Größen .| 


Wahl 


der statistischen Prozedur 


Festlegung der Schrittweite 


Festlegung des Zahlenbereichs 
und des Umfangs (Zeitraum) 


Ausführung der statistischen 


Prozedur 


Ergebnisausgabe 


Abb. 1: z Zyklusarbeit von MODAW 
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Fischer, J. 


Untersuchungen zur Simulation von Concurrent Pascal und Modula- 
Programmen 


4. Einführung 


Die Erstellung von Simulationsmodellen komplizierter Rechnersy- 
steme (Rechnernetze, verteilte Datenbanken, Multiprozessorsyste- 
me u.a.) sowie das computergestützte Experimentieren mit diesen 
Modellen hat sich als eine nützliche Methode hinsichtlich der 
Gewinnung von Aussagen zu Verhaltensverhersage, Leistungsvernö- 
gen, Leistungsverbesserung und Zuverlässigkeit dieser Systeme 
erwiesen. Die Attraktivität dieser Methode wächst in dem Maße 
wie es gelingt, sie bereits in den Entwurfsprozeß der Rechner- 
systeme (d.h. sowohl die Konzipierung der Hardwarekonfiguration 
als auch bei der Entwicklung der benötigten Software) mit einzu- 
beziehen /1/. Die Verwendung von leistungsfähigen höheren Pro- 
srammiersprachen mit speziellen Sprachkonstrukten zur Separie- 
rung unmittelbar maschinenabhängiger Teile (low-level-facili- 
ties) erweist sich dabei sowohl für einen rationellen und siche- 
ren Entwurf der Software als auch für deren Analyse als vorteil- 
haft. Concurrent Pascal/2/ und Modula/3/ sind solche Sprachen, 
die in der DDR inzwischen auch verfügbar geworden sind. 


Grundlage für die Verhaltensanalyse eines Rechnersystens mittels 
Computersimulation ist die Erstellung eines Modells (als Einheit 
von Hardware-, Software- und Arbeitslastmodell), das die wesent- 
lichen Eigenschaften des Originals hinsichtlich eines festgeleg- 
ten Untersuchungszieles widerspiegeln muß. Der Abstraktionsgrad 
des Modells wird dabei maßgeblich 

- von der Zielstellung der Simulationsstudie, 

- von der Komplexität des zu untersuchenden Systens, 

- von den rechentechnischen Möglichkeiten (Speicherplatz, 

Rechenzeit) zur Durchführung der Experimente am Modell 

- und vom Entwurfs- und Untersuchungsstadiun 
bestimmt. Je abstrakter nun dieses Simulationsmodell ist, um so 
größer ist jedoch der Aufwand für dessen Validierung. Die Vali- 
dierung erfordert den Nachweis der Äquivalenz von modelliertem 
und realem Verhalten des Rechnersystens bei Variation der Ar- 
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beitslast und festgelegter Bewertung. Dies ist meist der aufwen- 
digste Teil der Simulation. 


Der hier vorgestellte Ansatz verfolgt das Ziel, Programnierwerk- 
zeuge bereitzustellen, die es gestatten, auf einem leistungsfäh- 
igem Rechner A die Softwareentwicklung für ein Rechnersystem B 
(Multiprozessorsystem, Echtzeitsteuerungssysten, lokales Netz) 
vorzubereiten, ehe B zur Verfügung steht. D.h., auf A wird zu- 
nächst ein abstraktes Modell von B softwaremäßig zu realisieren 
sein und danach kann die Modellsoftwareentwicklung beginnen. Ei- 
ne wesentliche Bedingung für die Verwendung dieser Methode als 
entwurfsunterstützendes und entwurfsbegleitendes Werkzeug 
besteht in erster Linie darin, daß sich Modell- und Original- 
software ohne Schwierigkeiten in einander überführen lassen /4/. 
Ideal wäre es sicher, wenn die Modell- und die Zielimplementa- 
tionssprache zusammenfallen. Somit stellt sich die Frage nicht 
nur nach den Einsatzmöglichkeietn moderner Systemimplementa- 
tionssprachen schlechthin für die Simulation, sondern auch da- 
nach, ob es ‚gelingt, daß die Modellsoftware strukturäquivalent 
zur Orginalsoftware entwickelt werden kann. Dies ist keine tri- 
viale Angelegenheit, da z.B. weder Modula noch Ada eine Instan- 
zenbildung von Modulen bzw. von Paketen zulassen, was sofort zum 
Problem wird, wenn z.B; ein Modell eines verteilten Systens zu 
erstellen ist. i 


2. HSMOD - ein Werkzeug zur Modellierung von Hard- und Software 


Da es sich gezeigt hat, daß das Klassenkonzept von Simula/5/ 
mächtig genug ist, um als Modell für solche Sprachstrukturen wie 
CLASS, MONITOR und PROCESS von Concurrent Pascal oder wie MODULE 
und PROCESS von Modula zu fungieren und darüber hinaus Simula 
als höhere Programmiersprache effektive Mittel von Hause aus für 
die Simulation bereitstellt, wurde hier dazu übergegangen, ein 
Werkzeug für die Modellierung von Rechnersystemen in Simula 'be- 
reitzustellen. Hinzu kommt, daß hier keine Strukturverletzungen 
beim Übergang Modell-Original auf Grund der Möglichkeit der In- 
stanzenbildung von abstrakten Datenstrukturefi zu erwarten waren. 


HSMOD entstand als Spracherweiterung von Simula (Unterklassen- 
bildung von SIMULATION), wozu das System OASIS/6/ wesentliche 
Anregungen vermittelte. HSMOD unterstützt die Konstruktion von 
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abstraketn Geräten, Prozessoren und Übertragungskanälen, in dem 
es dafür vordefinierte Bausteine bereitstellt. Ebenso werden auch 
Bausteine zur Konstruktion der Modellsoftware bereitgestellt, wo- 
bei aber noch keine zielsprachtypischen Hilfsmittel bereitgestellt 
werden. Dies ist weiteren HSMOD- Erweiterungen vorbehalten. Die 
als abstrakte Datentypen umgesetzten Bausteine von HSMOD sind mit 
einigen ihrer wichtigsten Attributprozeduren in Abb.1 dargestellt. 
Die Pfeile deuten die Typerweiterungen (Unterklassenbildung) an. 


PROGRAM DEVICE 
- call - start \ 
- execute - stop PROCESSOR 
- work | 


- runner 
- interrupt 


Abb. 1 Bausteine von HSMOD 


Die Attribute von PROGRAM und PROCESSOR wurden so entworfen, daß 
ein PROGRAM-Objekt nur dann abgearbeitet wird, wenn es der augen- 
blickliche "runner" eines PROCESSOR-Objektes ist. Die "call"- 
Funktion wird innerhalb eines Modellprogramms dazu benutzt, um ' 
ein anderes PROGRAM-Objekt aufzurufen. Mit der "interrupt"-Funk- 
tion ist es möglich, die Abarbeitung des laufenden Programms ei- 
nes PROCESSOR-Objektes zu unterbrechen und eine entsprechende Be- 
handlungsroutine zu aktivieren. Mit "execute" läßt sich der Ve 
brauch von Modellzeit steuern. 


3. HSMOD- Erweiterung zur Nachbildung von Modula- Programmen 


Zunächst muß hier festgestellt werden, daß nur prozeßorientierte. 
Programme in die Betrachtung einbezogen werden. Das Hauptpro- 
gramm (Anwendungsmodul) wird als ausgezeichneter Prozeß im Mo- 
dell verhandelt. Die entsprechende Erweiterung von HSMOD zeigt 


HSMOD 
PROGRAM 
| Modula Environment 
COROUTINE 


- transfer 
- lotransfer 
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Abb. 2 Bausteine von Modula Environment 


Diese Vergehensweise wird derzeitig bei der Entwicklung des lo- 
kalen Rechnernetzes an der Sektion Mathematik der HUB erprobt. 
Im Vortrag wird darauf näher eingegangen. 


4. HSMOD- Erweiterung zur Nachbildung von Concurrent Pascal- 
Programmen 


Neben der Nachbildung von Konstruktionen wie RECORD, MONITOR, 
CLASS und PROCESS müssen bei der Nachbildung von Concurrent 
Pascal- Programmen auch Vorkehrungen für das Laufzeitsysten - 
Modell getroffen werden. Abb. 3 zeigt die entsprechenden Erwei- 
terungen. 


PROGRAM DEVICE HSMOD 
Concurrent Pascal 
CP PROCESS * CP DEVICE Environment 
- 10 P7ZAS 
ur DISK | . PARE 
MYPE PRINTER 
KERNEL SE TER 


Abb. 3 Bausteine von Concurrent Pascal Environment 
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In /7/ findet man ein Beispiel für ein auf dieser Basis model- 
liertes Concurrent Pascal-Progranmn. 
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Gugeı, Gerhard: 


"Konstruktion eines Dateninterface zur Kopplung funktionsorien- 


tierter Bausteinprogramme" ; 


\ 


Geforderte Variabilität von DV-Lösungen (Anwendungssystemen) 
ist erreichbar, wenn funktionsorientierte Bausteinprogramnıe 
kombiniert werden können ohne globale Auswirkungen als Folge 
ihrer Kopplung. Anerkannte Strategie ist informationelle kopp- 
lung über Daten-Schnittstellen, triviale Konstruktionsregel für 
das Interface ist Bilden der Vereinigungsmenge. der zu trans- 
ferierenden Informationen, das führt aber zu Interfaces mit ho- 
her Redundanz, 


Verbesserung durch Systematisieren und Generalisieren der Funk- 
tion der Information für ihre Verarbeitung ist möglich, Typi- 
sche Funktionen abstrahierbar in Teile des Dateninterface 

(1: Identifikationsteil; 2: Werteteil; 3: attributiver Teil). 
Besondere Bedeutung hat Trennung: 1: von 3: vor allem für Auf- 
gaben der sog, "kommerziellen DV" (Gruppenmerkmale in 3: I). 


Für die konkrete Aufgabenstellung "Innovation von (Stapel-) 
Programmen wegen sich ändernder Nutzeranforderung und neuer 
technologischer Angebote (Datenbankspeicherung, Dialogverar- 
beitung ...)" wurde ein konkretes Dateninterface (wird vorge- 
tragen) konstruiert und praktiziert für DV-Projekte der tech- 
nologischen Vorbereitung, Planung und kontrolle der Bauproduk- 
tion, 


Erkenntnis: möglich wurden 


- koppeln von Bausteinen nur im geforderten Funktionsumfang 


- Trennung (speicherkonkreter) Datenbasis von (spelcherneutra- 
ler) Programmbasis (Speicherung von Verarbeitung) \ 


- schrittweise Innovation bislang komplexer Progranıme 
- stärkere Arbeitsteilung bei Entwicklung 
Problem: noch keine sichere Aussage, ob Reduzierung des intwick- 


lungsaufwandes erkauft wird durch höheren Abarbeitungsaufwand 
wegen häufiger Exporte/Importe aus/in Standard-Dateninterface, 


Roland Henkel 4-32 


Erfahrungen mit der PSU auf der ES 1022 


Die PSU (Projektierungs - und Programmstützende Ungebung) ist 
ein Softwareprodukt des Leitzentrums für Annendungsforschung, 
des dem Nutzer eine UNIX - ähnliche Schnittstelle auf der 
Grundlage des OS/ES, sowohl in einer Stapelverarbeitungs - 
als auch in einer TSO - Variante bereitstellt. 

-Das Betriebssystem UNIX, das hier nachgebildet wird, gehört 
zu den verbreitetsten Betriebssystemen für Klein - und 
Mikrorechner, das sich durch eine moderne Architektur, koanfor- 
table Leistungen und eine etfiziente Dateivermaltung (Filo- 
system) auszeichnet. 

Am ORZ der Humboldt-Universität ist die PSU seit Anfang 1984 
im Einsatz, zunächst in einem Testbetrieb, dann zunehmend 
unter Einbeziehung weiterer Nutzer. Weiterhin wurde es für 
Praktika und andere Ausbildungsaufgaben eingesetzt. 
Vorwiegend nird im Dialogbetrieb unter TSO mit der PSU gear- 
beitet und hat sich für die Aufgabengebiete Progrannentnick- 
lung und Verwaltung der Nutzerdateien als besondere wirkungs- 
voll erwiesen. Die PSU kommt mit ihrer Architektur und ihren 
Kommandosatz einer Dialogarbeit besonders gut entgegen. Die 
Möglichkeit, mit denselben Werkzeugen und Kommandos, in derselben 
Umgebung die Arbeit außerhalb der Dialogzeiten im Stapel 
fortzuführen und zu ergänzen. führt zu einer Erhöhung der 
Effektivität der Arbeit bei geringem Aufwand. Der Nutzer muß 
sein Arbeits - und Testregime nicht aut den Stapel umstellen, 
wie es bei paralleler Nutzung von TSO und Stapel sonst oft 
erforderlich war. 

Im wesentlichen wurde bei der Arbeit mit der PSU wie folgt 
vorgegangen: Quelltext - und Objektmodulbibliotheken sowie 
andere nicht formatgebundene Daten wurden in das Filesystem 
der PSU übernommen. Dieses Filesystem bistet durch sine platz- 
sparende Abspeicherung, den direkten Zugriff zu beliebigen 
Datenbytes und vor allem durch seine Keorganisationsfreiheit, 
die zum Beispiel die sonst bei untergliederten Dateien des 
US/ES von Zeit zu Zeit notwendigen Kompreßläufe mit all ihren 
Getährdungen (Sytemabsturz, Maschinentehler, Data Checks) 
übertlussig macht, einen sehr großen Komfort bei einfacher 
Handhabung. 
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überhaupt muß betont werden, daß die PSU gegenüber unvorher- 


gesehenen Unterbrechungen der Arbeit bemerkenswert resistent 
ist. In der Regel befindet sich das Filesystem in einem 
definierten Zustand, der eine Weiterarbeit an. der Unterbrechungs- 
stolle bzw. an einem unmittelbar davorliegenden Punkte er- 
nöglicht. f 

Hervorzuheben ist der Editor der PSU, der durch die Vielzahl 
seiner Kommandos, der Schnelligkeit, mit der der editierte 

Text in das Filesystem zurückgsschrieben wird, gegenüber 
vergleichbaren Werkzeugen, zum Beispiel dem EDIT - Kommando 

des TSO deutliche Vorteile hat. 

Die Quelltexte können in der PSU - Umgebung eingegeben, editiert 
und übersetzt und der Objektcode für die spätere Verbindung 

im Filesystem abgelegt werden. Durch das Kommando LINK ist 

die Verbindung der Objektmoduln zu ausführbaren Programmen 
möglich. Unter Berücksichtigung einiger Bedingungen ist es 

auch möglich, die erstellten Lademoduln in der PSU - Umgebung 
aufzurufen. . 

Fast alle Aufgaben in einer Dialogsitzung können in der PsU - 
Ungebung ausgeführt werden, sodaß es kaum noch notwendig ist, 
in die TSO - Umgebung zurückzukehren. Hinzu kommt, daß die 
wichtigsten TSO - Kommandos (ALLOCATE, FREE und andere) eben- 
falle in der PSU aufgerufen werden können, 

Allerdings ist es zur Zeit noch so, daß Lademoduln zwar in 

der PSU - Umgebung verbunden, aber nur in einer 05 - Lade- 
modulbibliothek abgelegt werden können. Wünschensnert wäre 
‚hier, daß auch die Lademoduln im Filesystem gespeichert werden 
können. Auf diese Weise wäre der Nutzer gänzlich von 0S - Da- 
teien unabhängig. . 

Die PSU bietet mit den Kommandos EXP und IMP (exportieren und 
importieren von Files) Möglichkeiten, Daten zwischen 

05 - Dateien und dem Filesystem auszutauschen, so daß ein 
Verlassen der PSU und eine Weiterarbeit im TSO - oder Stapel- 
regine prinzipiell möglich und leicht zu bewerkstelligen ist. 
Spezifische Kommandos dienen zur Sicherung einzelner Files 

oder des gesamten Filesystems auf Magnetband und gegebenenfalls 
deren Wwiederherstellung. 

Quelltexteditierung und Programmentwicklung, die den Schwerpunkt 
der Arbeit der Nutzer am ORZ der Humboldt-Universität bilden, 
können ausschließlich in der PSU - Umgebung durchgeführt werden. 


Das Kommandokonzept der PSU, die Möglichkeit, eine Anzahl von 
Kommandos in Prozeduren zusammenzufassen sonie Drucklisten in 
die 0OS-Ausgabeklassen zu delegieren bieten ein umfangreiches und 
"handliches Spektrum für diesen Aufgabenbereich. 

Der PSU - Kommandosatz wird vom Hersteller und interessierten 
Anwendern laufend ergänzt. So eind zum Beispiel leistungs- 
fähige Kommandos zur Textverarbettung und - aufbereitung 
vorgesehen. 

Hinzuweisen ist darauf, daß ein Nutzer, der mit der PSU zu 
arbeiten gewohnt ist, ohne Schwierigkeit sich in die Anwendung 
eines UNIX - Betriebssystems auf. einem Klein - oder Mikro- 
rechner einfindet. Mit zunehmender Bedeutung und Verbreitung 
der Mikrorechentechnik, die unter Umständen die Arbeit auf 
verschiedenen Rechnern und Rechnertypen erzwingen, ist dies 

ein nicht zu unterschätzender Vorteil. Der Nutzer ist in der 
Lage, mit den gleichen Mitteln und Werkzeugen, die er bereits 
kennt, seine Aufgaben auf einem anderen Rechner zu lösen. 

Einen besonders hervorzuhebenden Geninn stellt die Bereitstellung 
des C - Kompilers für die PSU durch die Technische Hochschule 
Karl-Marxk-Stadt dar. Dieser ermöglicht nicht nur, auf einem 
höheren, sehr flexiblen Sprachniveau in die PSU nach Bedarf 
eigene Kommandos einzufügen - wobei ermähnt werden soll, daß 
die Schnittstellen zur PSU einfach und wohldefiniert sind - 
sondern setzt den Nutzer auch in die Lage, portable Programme 
herzustellen. Ein C - Kompiler ist in jedem UNIX - oder 

UNIX - ähnlichen Betriebssystem zu finden, UNIX selbst ist 

zum größten Teil in C geschrieben., Ein C - Text, der in der 
PSU ein ausführbares Programm liefert, dürfte auch auf jeder 
Anlage mit einem entsprechenden Betriebssystem ohne Umstände 
übersetzbar sein und dasselbe Programm, angepaßt an die ver- 
änderte Maschinenumgebung erzeugen. Dadurch ist Maschinenun- 
abhängigkeit und Portabilität in einem bisher nicht vorhandenen 
Maße gegeben. 

. Die Sprache C ist leicht erlernbar und verbindet den Komfort 
höherer Programmiersprachen mit den Möglichkeiten einer im 
gewissen, die Portabilität nicht beeinträchtigenden Maße 
maschinennahen Programmierung. Es wird ein Code’ erzeugt, dessen 
Verhältnis zum Assemblercode in der PSU etna 1 : 1,3 beträgt. | 


Die Schnittstellen zur Maschenehungebüng sind exakt definiert, 
es ist die Aufgabe des jeweiligen Kompilers, den für den 
konkreten Rechner geeigneten Code daraus zu erzeugen. 
Die PSU läuft am ORZ der Humboldt-Universität auf einem 
ES 1022 mit 512K Hauptspeicher bzw. in einer TSO - Region 
von 128K. 
Nach einjähriger: Arbeit mit der PSU kann eingeschätzt werden, 
daß die Installation einfach und reibungslos verlief (ausge- 
nommen einiger hardware-bedingten Schwierigkeiten, die in 
den aktuellen PSU - Versionen behoben sind), Die PSU ist 
inzuischen zu einem unentbehrlichen Werkzeug geworden. 

ORZ der 
Humboldt - Universität 
108 Berlin 
Unter den Linden 6 


Roland Henkel 
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Herrlich, O,; Schubert, W.; Altmeyer, K, 
KOKOZENT - ein Versuch zur Koordinierung der Entwicklung von 
Mikrorechnersoftware 


An der Sektion Informationsverarbeitung der MU-Dresden wurde 
ein Konsultations- und Koordinierungszentrum für Mikrorechner- 
software im MHF-Bereich unter besonderer Berücksichtigung der 
Automatisierung wissenschaftlicher Experimente geschaffen, 

Im Vortrag werden Ausführungen zu geplanten Arbeitsweisen und. 
-etappen sowie zu ersten dabei erreichten Kkrgebnissen gemacht, 
In diesem Zusammenhang werden folgende Aspekte zur Koordinie- 
rung der Entwicklung und Nachnutzung von Softwaresystenen be- 
trachtets 
1. Welche Voraussetzungen müssen in der Planungsphase von Au- 

tomatisierungsvorhaben seschaffen werden, um eine Koordinie- 
rung zum Zwecke:.der Rationalisierung zu erreichen? 

2. Wie muß die vorhandene Software spezifiziert sein, um eine 
Nachnutzung für andere Automatisierungsvorhaben zu gewähr- 
leisten? 

3. Welche Anforderungen an Softwarewerkzeuge zum Erstellen und 
Verwalten der Spezifikatinnan solcher Softwaresystene ste- 
hen bei der Lösung des Koordinierungsproblens ? 
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Dr. Jacob, Hans-Jürgen 


Projektierungsumgebung für den CCS-Rachnerverbund. 
1. Vorbemerkung 


Der CCS-Rechnerverbund basiert auf. dem Programmsystem 

Computer Communication Software des VEB Leitzentrum für Annen- 
dungs forschung Berlin. In der Version CCS3 wird der Aufbau von 
heterogenen Rechnerverbundsystemen auf Grundlage der gogen- 
wärtig in der DDR verfügbaren Datendienste (Handvermittoltes 
Datennetz, überlassene Übertragungswege) unterstützt 

(siehe /1/). 

Die funktionale Struktur des CCS-Rechnerverbunds zeigt Abb. 1. 


CCS-Datenübertra- 
®) gungssystems Synchrone Datenübertragung _ 
zwischen Rechnern im Konkurrenz-= , 
betrieb (BSC1) 


I) CCS-Netzdienste: Trensfersystome für Basiskommuni=- 
ketionsfunktionen (Netzdateiko- 
plerdienst, entfernte Bediener- 
kommunikation) 


e.) CCS-Projektierungs- 

Sy umgebungs Gesamtheit der Mittel für die Unter- 
stützung der Projektierung von 
"CCS-Anwendungslösungen 


3 CCS-Anwendungslö- 
sungen: Universelle (z.B. entfernte Auf- 
tragsabarbeitung), spezielle 
(z.B. verteilte Textverarbeitung) 
oder bereichsspezifische (z.B. 
Dateitransferservice im VE KDV) 
e\ verteilte Anwendung im CCS=-Rechner- 

verbund 


abbılı Funktionale Struktur des CCS=-Rochnervarbunds 
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Dio Projektierungsumgebung für den CCS-Rechnerverbund steht 
EDV-Projektanten für den Aufbau verteilter Anwendungen zur Ver- 
fügung. In folgendem sollen einige wesentliche Aspekte der Pro- 
Yektierungsumgebung für die Version CCS 3.1 (heterogener Ver- 
bund von ESER-EDVA und Bürocomputern) erläutert werden. 
Die programmtechnische Realisierung der Projektierungsumgebung 
für CCS 3.1 erfolgt in Form der Datei-Dienst-Programme NFSCOPY 
(ESER-EDVA) /2/ bzw. NFSC (BC) /3/. 


2. Kopierfunktionen der CCS-Projsktierungsumgebung 


Die Annendung von Datei-Dienstprogrammen für das Umspeichern/ 
Kopieren von Dateien ist sonohl für den EDV-Projektanten im 
OS/EC (z.B. IEBCOPY, IEHMOVE) als auch im SIOS 1520 (z.B. LBSV, 
COPD) eine gewohnte Arbeitsweise. Dem wird mit der Bereitstellung 
von Kopierfunktionen als Kernstück der CCS-Projektierungsumgebung 
Rechnung getragen. Da sich im Falle verteilter EDV-Projekte 
Eingabe- und Ausgabedsteien auf Datenträgern lokaler und entfern- 
ter Rechner befinden, ist im Unterschied zu lokalen Datei-Dienst- 
progremmen die Übertragung einer Zuischendatei. zwischen den 
Rechnern notwendig (Abb. 2). 


im — meer 


lokaler Rechner entfernter Rechner 
/-1-Ausgabedatei Eingabedateil--- 


Ausgabedatei 
) 


AmsenderdatesCJnotzdetei —z_, Netzdatei DrAnnondordazss. (er) 
on - | ! 


Eingabedatei 


©) Datei-Dienstprogramn 


Abb. 2: Prinzipieller Ablauf des Kopiervorgangs im CCS-Rechner- 
verbund 


Diese Zuischendatei besitzt ein netzeinheitliches Format (Netz- 
datei). Das CCS5-Kommunikationssystem kennt nur diese Netzda- 
teien. Entsprechende Dienste und Protokolle nehmen keinen Bezug 
auf die Dateien der Anwender. 
Die Beschreibung der Kopierfunktionen erfolgt getrennt nach den 
Komnunikationsformen 

ESER—»ESER/ESER—> BC/BC > ESER/BC —>BC 
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Folgende Dateiorganisationsformen werden unterschieden: 


PS-Dateien: Dateien, die von der 0S-Datenverwaltung als 
sequentielle Dateien aufgefaßt werden 

DA-Dateien: Direkt organisierte Dateien des OS mit und ohne 
Schlüssel s 

PO-Datoien: Untergliederte Dateien des 0S 


SIOS-Dateiens Sequentiell geschriebene Dateien auf Minidiskette 
oder Magnetbandkassette, auf die sequentiell oder 
direkt zugegriffen werden kann. 


In der CCS-Projektierungsumgebung unterstützte Kopierfunktionen 
sind: 


I._ESER-—3ESER 


1. PS-Dateien: 
- einfaches Kopieren 
z.B. . Kopieren: einer Banddatei 
« Kopieren einer sequentiell organisierten Platten- 
datei | 
- Kopieren zwischen Magnetband und Magnetplätte 
z.B. . Kopieren einer lokalen, sequentiell organisierten 
Plattendatei in sine entfernte Banddatei 
- Kopieren mit Umblocken (nur bei RECFM=F oder FB) 
z.B. Kopieren einer Banddatei mit Verkleinerung der 
Blocklänge 
= Kopieren von Beständen untergliederter Dateien 
z.B. Kopieren eines Jobs aus einer lokalen Jobbibliothek 
in eine entfernte Banddatei 
- Kopieren von Dateien im Systemeingabestrom . 
z.B. Kopisren von über Lochkartenleser eingegebenen Loch- 
karten in eine Banddatei 
= Kopieren von über Direktleser eingegebenen Dateien 
z.B. Kopieren von Lochkarten in eine sequentiell organi- 
sierte Plattendatei 
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2. DA-Dateient 
- einfaches Kopieren 
z.B. Kopieren eine Plattendatei mit Schlüssel 
- Kopieren mit Umblocken. (nur bei RECFM=F oder FB) 
z.B. Kopieren öiner Plattendatei ohne Schlüssel mit Vor- 
dopplung der Blocklänge 


3. PO=Dateiens 
- einfaches Kopieren 
z.B. Kopieren einer lokalen Bibliothek in eine neu zu 
erstellende entfernte Bibliothek 
= Kopieren aller Bestände einer PO-Datei 
z.B. Ergänzung einer entfernten Bibliothek um die Bestände 
einer lokalen Bibliothek 
- Kopieren von Beständen einer PO-Datei 
z.B. . Kopieren ausgewählter Bestände einer lokalen Biblio- 
thek in eine entfernte Bibliothek 
« Kopieren von Beständen einer lokalen Bibliothek in 
eine entfernte Bibliothek unter Ausschluß von 
Beständen j 
- Kopieren mit Ersatzen von Beständen 
z.B. Aktualisieren einer entfernten Bibliothek durch 
Anderungsstände einer lokalen Bibliothek 
- Kopieren. mit Umbenennen von Beständen 
z.B. Einbringen von Beständen einer lokalen Bibliothek 
mit neuen Namen in eine entfernte Bibliothek 


\ 


IL. EBER-—BC 


1. PS-Dateien: 

- Kopieren einer PS-Datei in eine SIOS-Datei auf Minidiskette 
z.B. Kopieren einer lokalen Banddatei in eine entfernte 
SIOS-Datei auf Minidiskette 

- Kopieren seiner PS-Datei in eine SIOS-Datei Auf Magnet- 
bandkassetk& 

z.B. Kopieren von über Lochkartenlesor eingelesenen Loch- 
karten in eine SIOS-Datei auf Magnetbandkassette 
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2. DA-Dateiens 
u Kopieren einer DA-Datei in eine SIOS-Datei auf Minidis- 
kette 
z«B. Kopieren einer lokalen DA-Datei in eine entfernte 
SIOS-Datei auf Minidiskette zur Weiterverarbeitung 
mit direktem Zugriff 
= Kopieren einer DA-Datei in eine SIOS-Datei auf Magnet- 
bandkassette. 
z.B. Kopieren einer lokalen Plattendatei in eine entfernte 
SIOS-Datei auf Magnetbandkassette zur Weiterver- 
arbeitung mit sequentiellem Zugriff 


3. PO-Dateieons 
= Kopieren von Beständen untergliederter Dateien als 
sequentielle Dateien 
z.B. Kopieren eines Bestands einer lokalen Bibliothek in 
eine SIOS-Datei auf Minidiskette 


Das Kopieren einer lokalen Datei im DKOI-Kode in eine entfernte 
Datei im KOI7-Kode ist bei allen Kopierfunktionen ESER—>»BC 
möglich. 

11T. BO--PESER 


= Kopieren einer SIOS-Datei in eine DA-Datei 
z.B. Kopieren einer lokalen SIOS-Datoi auf Magnetband- 
kassette in eine entfernte Plattendatei 
- Kopieren seiner SIOS-Datei in eine PS-Datei 
z.B. Kopieren einer lokalen SIOS-Datei auf Minidiskette 
in eine entfernte Banddatei 


Das Kopieren einer lokalen Datei im KOI7-Kode in eine entfernte 
Datei im DKOI-Kode ist bei allen Kopierfunktionen BC——ESER 
möglich. 
Iy._BE---2BC 
- sinfachos Kopieren 

z.B. Kopieren einer lokalen SIOS-Datei auf Minidiskette in 

eine entfernte, existierende Datei auf Minidiskette 

= Kopieren zuischen Minidisket£& und Magnebandkassette 

Z.b. Kopieren einer lokalen SIOS-Datei auf Minidiskette in eine 

"entfernte, existierende SIOS-Datei auf Magnetbandkassette, 


\ 
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Die entsprechenden NFSCOPY= bzw. NFSC-Läufe können auch auf 
nicht am CCS-Datenübertragungssystem angeschlossenen ESER-EDVA 
bzw. Bürocomputern durchgeführt werden (offline Auftragser- 
stellung). Die Übertragung der als zeischendatel entstehenden 
Netzdateien erfolgt nach deren Erzeugung automatisch, Jedoch 
hängt der Übertragungszeitpunkt von der Verfügbarkeit der ent- 
sprechenden Verbindung zwischen lokalen und entfernten Rechner £ 
ab. 
'Für den Abschluß des Kopiervorgangs auf Empfangsseite. (Erstellen 
Ausgabedatei aus Netzdatei) ist wiederum die Abarbeitung der 
Datei-Dienstprocramme NFSCOPY bzw. NFSC notwendig. Die dafür 
benötigten Informationen können dem NFS-Protokoll (ESER) bzw. 
NFSC-Protokoll (BC) entnommen werden. Im Falle periodisch ab- 
zuarbeitender EDV-Projekte werden entsprechende NFSCOPY-Jobs bzw. 
NFSC-Menues bereits am Empfangs-Rechner existieren. 
Bei Nutzung der Kopierfunktionen ESER——ESER besteht darüber- 
hinaus die Möglichkeit der Übergabe des NFSCOPY-Jobs gemeinsam 
‚mit den zu kopierenden Dateien. 


3. Netzdateisteuerfunktionen der CCS-Projektierungsumgebung 


Diese Funktionen beziehen sich auf 3 Komplexes 


1. Festlegung von ESER-EDVA/BC, auf denen die Netzdatei be- 
reitgestellt werden soll 


-' Bereitstellung auf einem bestimmten Rechner 
- Bereitstellung auf mehreren Rechnern 
Bereitstellung auf allen über das CCS-Daten- 
übertragungssystem erreichbaren Rechnern 
(Rundschreiben) 


nur ESER-ESER 
bzw. ESER>BC 


D 


« Verringerung des zu übertragenden Datenvolumens der Netzdatei 


Standardkomprimierung f 
Attributkomprimierung 
Schnittstelle für den Anschluß 
weiterer Komprimierungs-/ 
Dekomprimierungs=-Moduln 


nur ESER——ESER, 
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3. Verwaltungs funktionen 
« Realisierungs- und Verfallsfristen 
=» Zuordnung zu einer Abrechnungsnumner 
- Dateisicherung 


Die gegenwärtig verfügbaren Datendienste der DP erfordern 

eine konsequente Minimierung des zu übertragenden Daten- 
volumens. 

Leistungsfähige Komprimierungsverfahren, wie die datei- 
strukturabhängige Attributkomprimierung /4/, besitzen daher 

im Rahmen der CCS-Projektierungsumgebung einen besonders hohen 
Stellenwert. 
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Kiss, Gäbor: GUTS- ein neues Dialogsystem 


Das Dialogsystem GUTS - Gothenburg University Timesharing 
System - wurde entwickelt, um das TSO System zu ersetzen, da es 
gegenüber dem bekannten TSO-Betrieb zahlreiche Vorteile bietet. 
Die Anwendung spezieller Datenorganisationsmethoden auf System- 
platten und eine zweckmassig entwickelte Zugriffsmethode für 
die Datenübertragung zwischen der Zentraleinheit und den Terminals 
ermöglicht die bessere Ausnutzung der Ressourcen und die schnelle- 
re Antwortzeiten an den Terminals. 


Bedingungen der Inbetriebsetzung des GUTS 


Das Dialogsystem arbeitet grundsatzlich unter der Steuerung 
des 0S. Bei den Systemen MFT, MVT und SVS ist die Anwesenheit 
des HASP Untersystems unbedingt erforderlich, das das Eingabe- 
Ausgabe-Spooling ermöglicht und zusatzlich eine interne Reader 
Funktion anbietet. 

Als Terminal können die IBM 3270-Gerate - lokale und entfernt - 
verwendet werden. 

An.der Budapester Universitat ist eine ESER-I Anlage /R40/ 
in Betrieb, die unter der Steuerung von OS/MVT+HASP+GUTS arbeitet. 
Die Aufteilung der Zentralspeicher ist auf der untenstehenden 
Abbildung dargestellt. 
Zur Zeit sind 8 MERA lokal Terminals (EC 7910) an die Anlage 
"angeschlossen. 
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Der Aufbau und die Dienstleistungen des GUTS 


Das System GUTS arbeitet als selbstandige Aufgabe im Betrieb- 
system OS /genausowie HASP/. Dabei müssen die folgenden Dateien 
on line erreichbar zu sein: 

GUTS.LIBRARY - Bibliothek der Lademodulen, muss mit der Datei 
SYS1.LINKLIB verkettet sein 

GUTS.RORI - Rollin /Rollout Datei - Benötigt GUTS/TS 
/Entspricht SYS1.SWAP .bei TSO/ ’ 

GUTS.USERDIR - enthalt die Attribute der berechtigten Benutzer 

 /entspricht SYS1.UADS bei TS0/ 
GUTS.FILEDIR - praktisch das Verzeichnis der GUTS.LIBRARY 
GUTS.LIBRARY - Bibliothek, die die Benutzerbestande enhalt 


Ausser der obenerwahnten Dateien gibt es noch zahlreiche Hilfs- 
dateien, die die bequeme Arbeit unterstützen /Z.B. HELP Funktion/, 
aber der Einfachkeit halber hier nicht behandelt werden. 
Um das Konzept des Systems besser zu verstehen soll der Aufbau 
der GUTS.LIBRARY betrachtet werden. 

‚ Diese Bibliothek hat eine spezielle Datenorganisation. 
Die Benutzerbestande werden in verdichteter Form gespeichert 
wodurch der Plattenbereich cca 25% weniger belastet wird. 
Neben der Erhöhung der Datenübertragungsgeschwindigkeit hat 
diese spezielle Datenorganisation noch einen sehr wichtigen 
Vorteil, und zwar kann die Verdichtung der Bibliothek /COMPRESS 
INPLACE/ völlig vermieden werden. % 

Die Bestande der Bibliothek haben einen Namen in folgen- 

der Form: USERID.MEMNAME. Die logische Satzlange innerhalb 
eines Bestandes kann 1-132 Byteanzahl sein, dazu kommen noch 
2 Bytes, die für eine interne Zeilennumerierung verwendet 
werden. Physisch werden die einzelnen Rekords /Zeilen/ in 
variabler Byteanzahl gespeichert, abhangig von den Verdichtungs- 
möglichkeiten. Auf dem Bildschirm können die Zeilen der 
Benutzerbestande mit oder ohne interne Zeilennumerierung 
ausgeschrieben werden. 
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Die interne Zeilennumerierung ist ein grudsatzliches Hilfsmittel 
im Editmodus. 
Die Benutzerbestande können Quellmodulen oder sogenannten exec- 
procedure-Modulen sein. Als Benstandteil hat das System GUTS 
eine selbstandige Prozeduresprache, die auf viele Arten para- 
metrisiert werden kann und die Bildung internen Zyklen ermöglicht. 
Mit Hilfe der "token", Systemvariablen und GUTS-Kommandos können 
auch solche ausführbare Prozeduren geschrieben werden, dei keine 
interaktive Region benötigen. 

Da die Datei GUTS.LIBRARY ein Zentraler Informationsspecher 
ist, kann sie eine mehrbandige Datei sein /max. 16. Platten/. 
Wie die Abbindung darstellt, befinden sich - als residenter Teil 
des Systems - im normalen GUTS-Betrieb die Modulen GUTS/RJE und 
GUTS/TS im Zentralspeicher. 

Der erste Modul bietet die folgenden Dienstleistungen: 

- Edit-Modus /Zeilenorientiert oder full screen editor/ 

- Delegierung von Jobs Über den HASP-internen Reader zum OS 
- Disposition über die Ergebnisse der delegierten Jobs. 

Die druckbaren Ausgabedateien können auf Bildschirm, auf zentra- 

len Druckern oder in den GUTS-Bestand dirigiert werden. 

/Druckzeile max. 132 Charakter/ 

- Abfragemöglichkeiten über den Bearbeitungsstand der delegierten 

Jobs und Über den Systemzustand von 0S, HASP und GUTS. 

Der zweite Modul /GUTS/TS/ ermöglicht die interaktive Arbeit, 

und enthalt den oder die nötigen: Benutzerprogrammbereiche. 

Die Anzahl und Grösse der Benutzerprogrammbereiche werden wahrend 
der Generierung festgelegt, aber sie können beim Start des Systens 
vom Bediener verandert werden. Der Inhalt dieses Bereiches 

- wenn gleichzeitig von mehreren Benutzern beansprucht - wird in 
die Dabei GUTS.RORI aus- un eingelagert. 

Beim Start des GUTS wird nur der Modul GUTS/RJE in den Haupt- 
speicher geladen. Der zweite Modul - der vom Bediener durch ein 
Spezielles GUTS-Kommando gestartet werden kann - wird entsprechend 
‘ Benutzeransprüche gestartet. 

An der Universitat ist GUTS/RJE ganztatig in Betrieb, dagegen 
GUTS/TS nur einige Stunden, - je nach Vorbestellung durch die 
Benutzern. 
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Im interaktiv Betrieb stehen alle Programmiersprachen zur Ver- 
£ügung /FORTRAN, PLi, PLi Optimizer, COBOL, BASIC, ASSEMBLER/, 
aber auch in GUTS/RJE - im Editmodus - können die entsprechen- 
den Syntaxchecker verwendet werden. 
Da die GUTS.LIBRARY eine spezielle Datenorganisation hat, können 
die einzelnen Bestande mit Hilfe der gewöhnlichen 0S-Dienst- 
programme nicht erreicht werden. Um die gespeicherten Informati- 
onen auch im Stapelbetrieb gut behandeln zu können, wird mit 
dem GUTS ein Dienstprogrammpaket geliefert. Diese Programme 
ermöglichen die Modifizierung und Übersetzung der GUTS-Bestande 
sowohl als batch als auch interaktiv. 
Datenschutz und - sicherung 
Jede Bildschirmsitzung beginnt mit der Angabe der Benutzerkenn- 
zeichnung und des Kennwortes. /USERID, PASSWORD/. 
Die Eingabe der einzelnen und berechtigten Benutzerkennzeichnungen 
wird vom Systembetreuer durchgeführt. Der :Systembetreuer wird 
im Zuge dieses Prozesses diejenige Möglichkeiten bestimmen, 
die dem Benutzer zur Verfügung stehen. 
Das Kennwort kann vom Benutzer jederzeit verandert werden, aber 
man muss vorsichtig sein, da das Vergessen des Kennwortes alle 
weitere Arbeit unmöglich macht. In diesem Fall gibt es nur eine 
Möglichkeit, die Benutzerkennzeichnung zu löschen und erneut 
einzugeben. 
Die Benutzerkennzeichnung bestimmt eindeutig die Arbeitsmöglich- 
keiten des Benutzers: 
- Benutzung der interaktiven Region 
- Delegierung von Jobs 
- Möglichkeit zur Modifizierung der Accountinformationen und 

der Benutzerkennzeichnungen | } 
- Beschrankungen im Zusammenhang mit den Namen des delegierten 

Jobs i . 
- den Wert der Benutzerauthoritat /siehe unten/ 
Der Benutzeratuhoritatswert ist ein skalar Wert von 0 bis 15. 
Dieser Wert beschrankt die Arbeit im Zuge einer Sitzung folgen- 
dermassen: /grober Überblick/ 
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AUTH=0 Einfache GUTS-Kommandos, 
Herstellung und Update der eingenen Dateien 
Abhangig von der Benutzerkennzeichnung ist interaktive 
Arbeit oder Delegierung von Jobs möglich. 
Lesen OS-Dateien 

AUTH=4 Abfrägemöglichkeiten über den Zustand des OS und GUTS, 
Informationen über O0S-Dateien /z.B. LPDS/ 

AUTH=6 Eigene OS-Datei kann im Zuge der interaktive Arbeit 
als Ausgabedatei geöffnet werden. 

"Fremde" GUTS-Bestande können gelesen und beschrieben 
werden. 

AUTH=8 Beliebige OS-Datei kann gelesen /beschrieben werden 
/natürlich unter der Kontrolle des Schutzsystems des 05% 
GUTS-Schutzschlüssel der fremden Benutzern kann abge- 
fragt werden 

AUTH=12 Die GUTS-Instandhaltungs- und Sicherungsfunktionen 
können durchgeführt werden 

AUTH=15 Das Terminalkann als Bedienerkonsole verwendet werden, 
fast alle OS-Kommandos können ausgegeben werden. 


Ausser der Benutzerkennzeichnung, dem Kennwort und dem Benutzer- 
authoritatswert gibt es noch eine weitere Möglichkeit - den 
Schutzschlüssel - die Benutzerbestande vor unbefugtem Zugriff 

zu schützen. Der Schutzschlüssel ist eine vorzeichenlose Zahl 
von 0 bis 32767, und er kann beim Erzeugen - oder Umbenennen - 
des Bestandes definiert werden. 

Wenn der Authoritatswert eines Benutzers hoch genug ist, kann er 
fremde GUTS-Bestande lesen und schreiben, aber bei geschützten 
Bestanden ist das nur nach Angabe des Schlüssels möglich. 

Das Schutzsystem des GUTS is völlig unabhangig vom Schutzsystem 
des OS., Der Datum- und der Kennwortschutz des OS bleibt weiterhin 
wirksam. 

Die Benutzerbestande werden in der GUTS.LIBRARY gespeichert. 
Die maximale Grösse dieser Bibliothek sind 16 Platten /27 oder 
100 MB Platten/, und benötigt theoretisch keine Instandhaltung. 
Über die Verwendungshaufigkeit der einzelnen Bestande führt 
das System eine sehr umfangreiche Statistik, mit Hilfe deren ein 
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wirksames Archivierungssystem in Betrieb gesetzt werden kann. 
Je Benutzerbestand werden die folgenden Daten in die Datei 
GUTS.FILEDIR gespeichert: 


- Datum der Erstellung /oder Umbenennen/ 
- Datum der letzten Modifizierung 

- Datum des letzten Zugriff /z. B. Lesen/ 
= Platzbedarf in der Bibliothek. 


‚Die zur Verfügung gestellten Dienstprogramme ermöglichen es - 
entsprechend den obigen Informationen - die verfallenen und zu 
grossen Bestande auf Magnetband oder auf Magnetplatte zu laden. 
Bei Bedarf können die ausgelagerten Modulen auch schnell zurück- 
gespeichert werden. 

Der Sicherheit halber - wenn der Benutzer benötigt - kann die 
volle Kommunikation im Laufe der Sitzung in einer Hardcopy-Datei 
aufbewahrt werden. Diese Datei kann spater ausgewertet werden. 


Praktische Erfahrungen 

An der Budapester Universitat steht eine R40 Anlage, in Betrieb, 

‚die mit acht lokalen Bildschirmterminals /EC 7910/ verbunden ist. 

Das betriebene Operationssystem ist OS/MVT mit HASP. Seit einem 

Jahr ist das GUTS eingesetzt, das das TSO System ersetzt.hat. 

Laut den bisherigen Erfahrungen kann eindeutig ausgesagt werden, 

dass die Dienstleistungen des GUTS in jeder Hinsicht besser sind: 

- weiniger Hauptspeicheraufwand 

- Kürzere Terminalantwortzeiten /z. B: LOGON, LOGOFF, SAVE 
innerhalb 2 Sekunden/ 

- ein zuverlassigeres Datenschutzsystem. Die 0S-Dateien sind nur- 
für berechtigten Benutzer erreichbar 

- der Systemkatalog des 0S wird nicht belastet 

- das eigene Sicherungssysten ermöglicht die bequeme und wirk- 
same Instandhaltung der on line GUTS Dateien. Die verfallenen 
Benutzerbestande können systematisch und dokumentiert auf Mag- 
netband ausgelagert werden. 

- nach einen eventuellen Systemabsturz werden die aktiven Edit- 


Arbeitsbereiche aufbewahrt, und im Zuge einer spateren Sitzung 
\ 
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kann die vorherige Dateneingabe reibungsios fortgesetzt werden, 
/Die Aufbewahrung geschieht max. 7 Tage lang/ 

- die interaktiv gestarteten Programme - abhangig von der Berech- 
tigung des Benutzers - können alle 0S-Dateien erreichen, 
entweder in Input- oder Output-Modus. 

Die OS-Dateien können auch DSORG=DA oder DSORG=IS sein, im 
Gegensatz zum TSO. 
Ausser den obenerwahnten Möglichkeiten gibt es noch weitere 


Interfaces zu anderen Telekommunikationssystemen, z. B. CICS 
und SHADOW. | 


Literatur 
1/ GUTS Installation Manual Ref: AS-2003-3 1982 
2/.GUTS Reference Manual Ref: AS-2001-3 1982 
3/ GUTS System Manual Ref: AS-2005-2 1981. 
Verfasser: 


Dr. Kiss, Gäbor 

ELTE Szämitöközpont _ 
1117 Budapest 
Bogdänffy u. 10/b. 
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Ingb Schriege, Reinhold Schonefeld 


Prograrmierwerkseuge unter dem Betriebssysten NUTOS 1630 


MUTOS 1630 (multi user timesharing operating systen) 
ist eine Entwlioklung von INEUM Leningrad, VEB Kombinat Robo- 
tron und der Technischen Hochschule Ilmenau für den Klein- 
rechner K1630. Dieses Betriebssystem ist kompatibel zu dem 
Betriebssystem UNIX - Version 7 /1/. 


MUTOS ist ein dialogfahiges Betriebsystem, das durch 
folgende Eigensohaften gekennzeichnet ist: 


- ein hierarchisches: Filesysten; 

- die Kompatibilität zwischen Files, Geräten und der 
Interprozess-E/A; 

- die Moglichkeit, asynohrone Prozesse zu schaffen; 

- eine universelle Systemkommandosprache; 

- ein hoher Grad an Portabilitat; 

- eine einfache Handhabung einer grossen Anzahl von Sy- 
stemrufen; 


Unter MUTOS sind eine Reihe Programmierwerkzeuge 
implementiert, die dem Nutzer eine effektivere 
Softwareentwioklung gestatten. Die wichtigste Programmier- 
sprache des MUTOS 1630 ist C /2/. Fast alle Kommandos und 
etwa 90% des Betriebssystemkerns sind in C geschrieben.- C 
ist eine hohere Programmiersprache, die durch ihre ökonomi- 
sche Schreibweise der Ausdrücke, die effiziente Programnab- 
laufsteuerung, die Fähigkeit, Datenstrukturen zu definieren, 
sowie einen grossen Satz von Operatoren und Datentypen 
charakterisiert ist. 


Aus der Menge der vom Nutzer zu verwendenten Progranm- 
mierwerkzeuge sollen hier die Sprachentwicklungswerkzeuge 
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näher beträchtet werden. Dies sind universelle Hilfsmittel 
für alle Programme. mit strukturierbarer Eingabe. 


Wir wollen ein Werkzeug verstehen als ein Programm, das die 
Maschine nutzt ünd ein allgemeines Problem löst. Damit viele 
Nutzer dieses Werkzeug verwenden, soll es leicht zu "handha- 
ben sein. 


Hieraus ergeben sich .folgende Forderungen an 
Softwarewerkzeuge: 


- sie mussen gut entworfen sein, damit der Leser die 
Moglichkeit hat, Programme zu erstellen, die leicht 
zu pflegen und zu ändern sind; 

- sie mussen hutzerfreundlich sein, um einen gewissen 
Anwenderkomfort zu gewährleisten; 

- sie müssen zuverlässig sein, ‚um die Richtigkeit der 
erzielten Ergebnisse garantieren zu konnen; 

- sie mussen effizient sein, damit man sioh die Programn- 
ausführung auch leisten kann; 


Vorteile und Eigenschaften von Softwarewerkzeugen: 


_ schnellere Erzeugung von Softwareprodukten; 

_ generierte Programme arbeiten korrekt; 

- Anwenderwunsohen kann schneller Reohnung getragen wer- 
den, 8. h. eine schnelle Änderung des Problementwurfe 
ist möglich; 

- Unterstützung der Portabilität, im Hinblick auf die Lö- 
sung allgemeiner Probleme (auf verschiedenen Rechnern); 

- Zerlegung des Problems in leichter zu übersohauende 
Teilaufgaben; 

-_ Nutzung von ausgefeilten Algorithmen und Spezialkennt- 
nissen, die die Voraussetzung guter Programmierwerk- 
zeuge sind; 
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In diesem Vortrag soll, wie schon erwähnt, auf Sprach- 
entwicklungswerkzeuge unter MUTOS 1630 näher eingegangen 
werden. Speziell werden die Programme zur Erzeugung eines 
syntaktischen Analysators /Yaoo/ und zur Erzeugung eines 
lexikalen Analysators /Lex/ sowie deren Zusammenarbeit vor- 
gestellt /3/. 


Yaoo - Yot another Oompiler Compiler 


Yaoc ist ein Programmgenerator. Dieser. generiert syn- 
taktische Analysatoren (Parser) aus einer Eingabespezifika- 
tionssprache, die die gewünschte . Syntax beschreibt. Yacc 
behandelt eine grosse Menge kontextfreier Grammatiken. In 
Abb. 1 ist ein einfaches Beispiel einer Yacc- 
Eingabegrammatik dargestellt. 


\ 


datun ı tag "." monat jahr; 


monat . "Jan" | "Feb" | "Marz" | Apr" | "Mai" | "Jun"| 
"Jul | "Aug" | "Sep" | "Okt" | "Nov" | "Dez" ; 

tag : zahl ; 

jahr ı zahl | ; 

zahl ZIFFER 


I zahl ZIFFER 


Abb. 1 Eingabegrammatik für Yaoc 


Das datum wird definiert als tag „ gefolgt von einen 
Punkt, monat und jahr. Semikolon und Doppelpunkt sind syn- 
taktische Zeiohen zur Definition der linken Seite und der 
Beendigung einer Regel. Der. senkrechte Strich kennzeichnet 
Alternativen einer Regel, die Hochkommas schliessen Literale 
ein. monat ist daher entweder "Jan" oder "Feb" u.s.w. Ein 
jahr ist entweder eine sahl oder es kann weggelassen werden. 
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In unserem Fall wäre alsc ein Datun 
3. Marz 1985 oder 3‘, Feb . 


Eine zahl ist entweder eine ZIFFER, oder eine sahl, gefolgt 
von einer ZIFFER. Mit jeder Grammatikregel kann eine Aktion 
verbunden werden, d.h. ein Programmfragment in einer be- 
stimmten Programmiersprache. Diese Programmstücken sind in 
unserem Fall in C geschrieben. Jedes Element einer Regel 
besitzt einen Wert oder eine Bedeutung. Die Aktionen sollen 
den Wert oder die Bedeutung der linken Seite der aktuellen 
Regel berechnen, Aus diesem Grund wurde ein .Mechanismus 
geschaffen, der diesen Programnfragmenten die Werte der 
Elemente der Regeln übergibt. Ausserdem kann man mit diesen 
Mechanismus auch den Wert der aktuellen Regel an andere 
Regeln übergeben. Betrachten wir die Regel für zahl aus 
unserem Beispiel. Jede ZIFFER besitzt einen Wert. Man kann 
nun eine Aktion einbauen, die den dezimalen Wert der zahl 
berechnet. Die Werte der Komponenten der rechten Seite der 
Regel werden durch die Pseudovariablen mi, mM ,„.. 
beschrieben (siehe Abb. 2). Der Wert der aktuellen Regel 
wird mit un übergeben. 


zahl 


ZIFFER 

{mmem;)} 
| zahl ZIFFER 
{mem «40 +m2 ;} 


Abb. 2 Wertübergabe mittels Aktionen 


Nach dem Einfügen dieser Aktionen können alle Regeln, 


die die Regel zahl verwenden, auf den Wert der zahl 
zugreifen. 
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Um die Eingabezeichenfolge zu lesen und sie in lexikale 
Einheiten (Token) umzuwandeln, ist ein lexikaler Analysator 
nötig. Der lexikale Analysator wandelt z.B. eine Folge von 
alphabethischen Zeichen in Namen um, erkennt Zeichenklassen 
(zB. ZIFFER'n) und behandelt Leerzeichen, Kommentare, New- 
lines und ähnliche Dinge. Solche Programme können u.a. auch 
mit dem Programmgensrator Lex erstellt werden. Durch das 
Analyseprogramm konnen dem aufrufenden Parser die mit den 
gelesenen Token verbundenen Werte übergeben werden. Wird 
die oben angegebene Grammatik mit Yaoo übersetzt, so liest 
der Parser, in Verbindung mit einem lexikalen Analysator, 
nur Daten. Er überprüft, ob die Zeiohenfolgen der Eingabe. 
dieser Grammatik entsprechen oder ob die Eingabe fehlerhaft 
ist. i 


Dem Nutzer werden von Yacc einige Vorteile angeboten. 
Ihn wird die Möglichkeit gegeben, die Arbeit des Parsers zu 
kontrollieren, wenn ein Fehler in der Eingabe entdeckt 
wurde. Die Fehlerstabilisierung kann mit zusätzlichen Regeln 
ermoglicht werden. In diesen Regeln wird ein Token "error" 
verwendet, um den Punkt der Fehlerstabilisierung zu 
kennzeichnen. Existiert z.B. eine Regel für ein Statenent, 
in der jedes Statement mit einem Semikolon abgeschlossen 
werden muss, so kann man die Überprufung der Eingabe nach 
Fehlerauftritt bei diesem Semikolon fortsetzen. Die Regel 
dazu hätte folgendes Aussehen: 


statement : error ';' 


Ein weiterer Punkt, der grosse Beachtung verdient, ist 
die Semantikstabilisierung, d.h., wie kann man z.B. 
Symboltabelleneintrage oder Ausdrucksbäume "reparieren", 
wenn Fehler nach diesen Einträgen aufgetreten sind. Yacc 
besitzt eine sehr nutzliche Eigenschaft, die es dem Nutzer 
‚erlaubt, arithmetische Ausdrücke zu spezifizieren. In den 
meisten Sprachen gibt es eine Menge von Operatoren (z.B. 
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+,=,/,*%,...);5 diesen kann durch Yaoco ein Vorrang zugeordnet 
werden. Der Ausdruck 

a+tb*o 
bedeutet eigentlich 

a+(b*e) 
da die Multiplikation hoheren Vorrang als die Addition hat. 
Man kann einfache Regeln in der Yacc-Grammatik angeben, in 
denen die Vorranginformation für die einzelnen Operatoren 
enthalten ist. 


left !+! I! 
Gleft 'xr 1% 


bedeutet, dass Addition und Subtraktion geringeren Vorrang 
als Multiplikation und Division besitzen. Alle Operatoren 
sind linksassoziativ. Diese Eigenschaft bedingt nicht nur 
einfacher zu sohreibende Grammatiken, sondern es werden auch 
sohnellere und kleinere Parser generiert. 


Der generierte Parser wird von Yaco in einem Unterpro- 
gramm yyparse untergebracht. Dieses Programm stellt einen 
deterministischen Kellerautomaten dar /4/, der durch die 
Eingabe, einen Zustandskeller und eine Zerlegungstabelle 
gekennzeichnet ist. Angenommen, der lexikale Analysator 
liefert für die auf Abb. 1 angegebene Grammatik die folgende 
Tokenfolge: 

ZIFFER ZIFFER '.' Feb 


Der Parser erhalt also das erste Token .Z2IFFER, das er im 
Keller abspeichert. Aus der Zerlegungstabelle wird erkannt, 
das ZIFFER die rechte Seite einer Regel ist. Diese Regel 
wird "reduziert", d.h. ZIFFER wird ausgekellert und an 
dessen Stelle wird die linke Seite der Regel (sahl) 
eingekellert. Das nächste Token (ZIFFER) wird gelesen und 
abgespeichert. Im Keller befindet sich. jetzt die Symbol- 
folge 
zahl ZIFFER 

Aus der Grammatik ist zu ersehen, dass dies die rechte Seite 
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der letzten Regel ist. Diese Regel wird, wie oben dar- 
gestellt, reduziert, und im Keller befindet sich nun noch 
das Symbol zahl. Tritt in der Eingabe kein weiteres Token 
ZIFFER auf, so wird zahl als rechte Seite der Regel für tag 
aufgefasst und reduziert. Vom lexikalen Analysator wird nun 
das Zeichen '.' (Punkt) übergeben. Dieses Symbol wird in 
den Keller gebracht und nach dem nächsten Token gefragt. Der 
Parser erhält "Feb", und da "Feb" der Regel monat 
entspricht, befindet sich nach dem Reduzieren dieser Regel 
die folgende Symbolfolge im Keller: 
tag '.' monat 

Diese Folge von Symbolen stellt die rechte Seite der Regel 
datun dar. Nach Reduzierung dieser Regel ist die Eingabe 
vollstandig abgearbeitet. Die Eingabe wurde als gültiger 
Satz unserer Beispielgrammatik erkannt. Parseraktionen wer- 
den beim Erkennen einer Regel ausgeführt, d.h., bevor die 
Symbole ausgekellert werden, wird das mit der Regel verbun- 
dene Programmfragment abgearbeitet. 


Zusammenfassend ist zu sagen, dass Yacc ein Werkzeug 
für die Generierung von Parsern liefert, die eine 
umfangreiche Klasse BNF-ähnlicher "Grammatiken akzeptieren. 
Yaoc besitzt gute Eigenschaften für die Fehlerstäbilisie- 
rung, die Spezifikation von Operatorvorrangen und die Angabe 
von Aktionen für erkannte Regeln. Es stellt einen Pro- 
grämmgenerator dar, der fur seine Arbeit einen lexikalen 
Analysator benotigt. Im folgenden Absohnitt wird’ ein 
Werkzeug zur Generierung solcher lexikalen Analysatoren vor- 
. gestellt. 


lox - nn FrFOGFSEm zur E-beneriafuug: jez!kaler Analysatoren 


Lex wird ähnlich verwendet wie Yaco. Die Eingabespezi- 
fikation für Lex ist wie bei Yaoc eine Folge von Regeln und 
dazugehörigen Aktionen. Auch hier wird eine Aktion abgear- 
beitet, wenn die entsprechende Regel erkannt wurde. Der 
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Hauptunterschied besteht in der Art der Eingabespezifika- 
tion. Yacc akzeptiert BNF-ähnliche Regeln, die aus Token 
aufgebaut sind. Diese Token setzen sich wieder aus ver- 
schiedenen Zeichen zusammen, die die BNF-Beschreibung nicht 
beinhaltet. Lex liest die Zeichen von der Eingabezeichenfol- 
“ ge direkt. Die Eingabespezifikationssprache für Lex beruht 
auf der Theorie der regulären Ausdrücke /4/. Diese Klasse 
von Regeln bedingt, dass Lex lexikale Analysatoren gene- 
riert, die deterministische Kellerautomaten darstellen (also 
genauso wie bei Yacc). Gleichzeitig bedeutet das, dass. auch 
für umfangreiche Eingabebeschreibungen der OTREUEER Genera- 
tor sehr schnell arbeitet. 


Die Aktionen, die vom Nutzer geschrieben werden, werden 
in der Reihenfolge, in der die entsprechenden regulären 
Ausdrücke in der Eingabezeichenfolge erkannt werden, abgear- 
beitet, Lex generiert lexikale Analysatoren, die auch 
mehrdeutige Spezifikationen akzeptieren. Sie wählen die 
Regel aus, die die längste mogliche Zeichenfolge des Einga- 
bestrons erkennt. Um z.B. bestimmte Wörter (angenommen 
"Bleistift") aus dem Eingabetext zu löschen, ist folgende 
Regel notig: 


%% 
Bleistift ; 


Das Zeichen "%%" kennzeichnet den Beginn des Regelteils von 
Lex. Der reguläre Ausdruck entspricht hier genau dem Wort 
"Bleistift". Es wird keine Aktion angegeben, d.h. das Wort 
wird beim Erkennen ignoriert. Alle Zeichen, die nicht in 
irgendeiner Regel bearbeitet werden, werden direkt in die 
Ausgabe kopiert. Angenommen, wir wollen im obigen Beispiel 
noch Kugelschreiber in Füller umwandeln, so kommt noch die. 
folgende Regel hinzu: 


7% 
Bleistift ; 
Kugelschreiber printf("Füller"); 
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Der Kellerautomat, der für diese Quelle generiert wird, 
sucht in der Eingabe nach beiden Zeichenfolgen (sprich 
Wortern) und arbeitet die angegebenen Aktionen ab, wenn er 
das entsprechende Wort erkannt hat. Im allgemeinen sind die 
Aktionen, wiederum wie in Yacc, C-Programmfragmente. Die 
Zeichenfolge, die durch die Regel erkannt wurde, kann in 
einem Feld abgelegt werden. Dieses Feld von Zeichen heisst 
yytext. In den Aktionen kann man dieses Feld veryenden, um 
auf die gelesenen Zeichen zugreifen zu konnen. 


Die Struktur der Ausgabe von Lex ist ahnlich. der von 
Yaoc. Es wird ein Unterprogramm yylex generiert, das den 
deterministischen Kellerautomaten darstellt. Yacc ruft 
standardmassig immer diese Funktion yylex auf. Jede Regel, 
die einen Token erkennt, muss einen Wert übergeben, der die 
Art des gelesenen Tokens kennzeichnet: 

return( Tokennumner ); 
Ein Wert, der mit dem Token verbunden ist, kann der Varia- 
blen yylval zugewiesen werden. Vom aufrufenden Programm kann 
man auf diese Variable direkt zugreifen. 


Ein regulärer Ausdruck kennzeichnet eine Menge von 
Zeichenketten, die erkannt werden sollen. Sie enthalten 
Textzeichen und Operatorzeichen. Die Ziffern und die 
Buchstaben des Alphabets sind immer Textzeichen. D.h. 

register 
erkennt die Zeichenkette "register" (egal, wo sie auftritt) 
und 

15DD7q 
erkennt die Kette "45DD7a". Die standardmassigen Sonder- 
zeichen in C, wie \n (Newline), \t (Tabulator) oder \b 
(Backslash), können hier auch verwendet werden.. Unter lex 
gibt es die folgenden Operatoren mit ihren entsprechenden 
Verwendungsmöglichkeiten: 
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1. * : bedeutet die null- oder mehrmalige Wiederholung 
eines regulären Ausdrucks; 
+ : bedeutet die ein- oder mehrmalige Wiederholung 
eines regulären Ausdrucks; 
2. ? : stellt die alternative Auswahl von Ausdrücken dar; 
3. | : Auswahl. von 2 oder mehreren Mustern (Zeichenfolgen); 
4. “ x: erkennt den Beginn einer Textzeile und 
og: erkennt das Ende einer Zeile; 
5. .(Punkt) : stellvertretend für alle Zeichen, 
ausser fur Newline; 


6. (.und ) : diese Klammern gruppieren Ausdrücke; 

7. und " : dienen dazu, Sonderzeichen ,zu kennzeichnen; 
8. [ und ] : diese Klammern definieren Zeichenklassen;- 
9. { und } : Zugriff auf definierte Zeichenfolgen; 

10. / : Kennzeichnung von Kontextbedingungen; 


Einige einfache Beispiele: 


[0-9] erkennt die einzelnen Ziffern von 0 bis 9; 

[0-9]+ erkennt Ziffernfolgen einer oder mehrerer Ziffern; 

-?[0-9]+ erkennt Ziffernfolgen mit wahlweise 
vorangestelltem Minuszeichen; 

[A-Za-z][LA-Za-z0-9]* 
erkennt alphanumerische Zeichenfolgen, die mit 
einem Buchstaben beginnen (wird oft für das 
Erkennen von Bezeichnern verwendet); 


Die Regeln von: Lex konnen geringe Kontextinformationen 
verarbeiten. Die beiden einfachsten Operatoren hierfür sind 
*” und a. Ist das erste Zeichen eines Ausdrucks "*", so wird 
der Ausdruck nur zu Beginn einer Zeile erkannt, d.h. nach 
einem Newline, oder am Anfang der Eingabe. Ist das letzte 
Zeichen ein "an", so wird der Ausdruck nur am Ende einer 
Zeile erkannt. Der Kontextoperator "/" bedeutet, dass der 
Ausdruck 
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ab/cd 


die Zeichenfolge "ab" nur dann erkennt, wenn ihr "cd! folgt. 

Obwohl Lex für die Kompilerkonstruktion entwickelt 
wurde, kann es auch in anderen Fällen Verwendung finden. So 
z.B. als Übersetzungsprogramm oder als Teil eines portablen 
Optimierers. In diesem wurden die regulären Ausdrücke dazu 
verwendet, den Optimierer an verschiedene Assembler anzu- 
passen /3/. 


Zusammenarbeit zwischen Lex und Yaco 


Da Yace Parser generiert und Lex als Generator für le- 
xikale Analysatoren verwendet werden kann, ist es sinnvoll, 
diese beiden Werkzeuge zusammenarbeiten zu lassen. Sie 
können als "Frontend" eines Kompilers verwendet werden. 
Hierzu sind allerdings zwei Dinge notwendig. Erstens eine 
Beschreibung der Zeichenfolgen, die die Token darstellen 
sollen. Diese Beschreibung wird mit Hilfe der regulären 
Ausdrucke gemacht. Zweitens die Beschreibung der Syntax der 
gewunschten Sprache in Form von Grammatikregeln. Yacc und 
Lex generieren aus diesen Beschreibungen die entsprechenden 
Progranne für die lexikale und syntaktische ‚Analyse. Diese 
Programme konnen zusammen kompiliert werden und ergeben ein 
abarbeitbares Programm. Dieses Programm liest die Eingabe, 
teilt sie in entsprechende Token auf und übergibt diese 
Token dem Parser. Der Parser organisiert dann die Eingäbe 
mittels der Token in eine bestimmte Datenstruktur der 
gewunschten Sprache. 


Das Yaccprogramm ist immer mit yyparse benannt und das 
Lexprogramm mit yylexz. Von yyparse wird yylex aufgerufen, 
so dass sich die Zusammenarbeit der beiden Programme wie in 
Abbildung’ 3 darstellt. | 


4-64 


lexikale Grammatik- 
Regeln regeln 

1? | 

| | 

ac | IE ER | 
l Lex | Il Yacc | 
| | | | 

| | 

| | 
777 | Kerzen | 

Eingabe ------>| yylex | ---—->| yyparse j EEE, > Ausgabe 


mo m. nn .. m oo... - ro... 


Abb. 3 Zusammenarbeit zwischen Yacc und Lex 


Schlussbemerkungen 


Schafft man in einem Betriebssytem eine Menge von Pro- 
grammierwerkzeugen, so bietet das eine grosse Flexibilität 
und einige wesentliche Vorteile. Diese Werkzeuge 
unterstutzen die Modularität und finden oft auch ausserhalb 
der fur sie definierten Umgebung Verwendung. Während für 
die Erstellung von Werkzeugen eine gute Theorie von grossem 
Nutzen ist, muss man allerdings auch einige Hinterturen für 
solche Probleme offenhalten, die man mit diesen Theorien 
nicht bearbeiten kann. Es ist wichtig, sich mit den theore- 
tischen Grundlagen zu befassen. Verwendet man z.B. ein 
theoretisches Modell, das sich als ungenügend erweist, als 
Grundlage eines Softwarewerkzeugs zu dienen, so ist es 
sinnvoll, diese Theorie weiterzuentwickeln, um neue und 
bessere Werkzeuge zu produzieren. Zum Schluss sei hier noch 
angefügt, dass die Erstellung von Softwarewerkzeugen mit der 
Verbesserung der allgemeinen Programmierumgebung unmittelbar 
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verbunden ist. Dieser Artikel wurde z.B. mit dem Progan- 
mierwerkzeug "nroff" erstellt. "nroff" ist ein Textverar- 
beitungsprogramnm, das unter MUTOS 1630 implementiert ist. 
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Programmentwicklung und Datenverwaltung 


1. Einleitung 


Mit der steigenden Komplexität von Software werden bessere 
Möglichkeiten zu deren rationeller Produktion erforderlich. 
Es ist dabei das Ziel, diesen Entwicklungsprozeß einheitlich 
über alle seine Phasen, von der Spezifikation bis zur Fertig- 
‚stellung der Software, einschließlich der dazugehörigen Do- 
kumentation zu führen. In jeder dieser Phasen entstehen neue 
Daten, alte Daten verfallen oder müssen an die nächste Phase 
weitergereicht werden. Deshalb kommt einer leistungsfähigen 
Datenverwaltung (DV) große Bedeutung zu. 


Die von den meisten Betriebssystemen angebotenen Wöglichkeiten 
zur Datenverwaltung sind jedoch 1.allg. an den physischen 
Speicherformen orientiert. Der Nutzer muß sich diesem Regime 
und seinen Datenobjekten wie Bibliotheken, Bestände usw. unter- 
ordnen. Das entspricht aber nicht: der Arbeits- und Denkweise bei 
der Softwareentwicklung. Dort geht es um die Entwicklung von 
Programmen, die z. B. aus Moduln und Routinen bestehen können 
sowie um deren Dokumentation. Es zeigt sich, daß es einer 
speziellen Datenverwaltung bedarf, um den Softwareentwicklungs- 
prozeß aktiv unterstützen zu können /Ko82/. 


Die folgenden Ausführungen befassen sich mit einigen speziellen 
Problemen der Datenspeicherung innerhalb von Programmentwick- 
lungssystemen (PES). Dabei wurde besonderer Wert auf eine hohe . 
Sicherheit für die gespeicherten Daten gegenüber Verlusten 
durch Betriebssysten- u. a. Fehler gelegt. 


Eine Implementation einer solchen DV in der Programmiersprache 
PASCAL befindet sich gegenwärtig in der Entwicklung. 
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2. Merkmale einer Datenverwaltung für Programmentwicklungssysteme 


Es gibt einige Merkmale, denen eine solche DV genügen muß: 
- Handhabbarkeit: 5 


Es muß eine Nutzerschnittstelle existieren, die den Zugang zu 
den Daten auf einem hohen Niveau realisiert, die aber gleich- 
zeitig einfach aufgebaut und leicht erlernbar ist. Das Fite- 
system XFS /Ro82/ bietet z.B. auf der Basis von UNIX /RT74/ 
eine Reihe zusätzlicher Dienste wie Sicherungsalgorithmen und 
zugriffsstatistiken an, wobei weitestgehend das bekannte UNIX- 
Filesysteminterface beibehalten wurde. Dadurch kann der Nut- 
- zer mit bekannten Namen und Begriffen operieren, was die Ak- 
zeptanzschwelle herabsetzt. 

Für die Handhabbarkeit einer DV ist es ebene wichtig, 

daß notwendige Wartungsarbeiten auf ein Minimum reduziert 
werden, so daß die Entwicklungsarbeit davon nicht beein- 
trächtigt wird. Das erfordert i. all. reorganisationsfreie 
Speicherstrukturen /HHNT84/. 


- Portabilität:z. 


Moderne Software sollte so beschaffen sein, daß ihr Einsatz 
auf verschiedenen Rechnerfamilien (ESER, SKR, BC, ...) möglich 
ist. Die Implementation muß daher in einer Programmiersprache 
erfolgen, die zwei Eigenschaften besitzt: 


. Verfügbarkeit für die infrage kommenden Rechner 
(als Grundbedingung), 
- „ Unterstützung eines Modulkonzepts« 


Die zweite Eigenschaft wird gefordert, um eine Schichtenar- 
chitektur der DV-Software zu ermöglichen. Dies ist notwendig, 
um eine klare Trennung der verschiedenen. funktionellen Ebenen 
zu realisieren. Das gilt vorallem für die Schnittstel’en zwi- 
schen den maschinenabhängigen und maschinenunabhängigen Teilen 
der Software, da dort bei einer Portierung der DV-Software oft 
‘umfangreiche Anpassungsarbeiten erforderlich sind. 


- Offenheit: a=6B 


Unter diesem Begriff sollen zwei Aspekte betrachtet werden: 
die wahlweise Nutzung von Systemkomponenten und der Daten- 
transfer. Aufgrund der oben diskutierten Forderung nach 
Portabilität macht sich beim Übergang von einem Rechner zu 
einem anderen u. U. eine Auswahl von Teilen der DV-Software 
erforderlich. Das kann z. B. durch unterschiedliche Haupt- 
speichergrößen oder Betriebssystemkomponenten nötig sein. 
Eine Schichtenarchitektur unterstützt eine solche optionale 
Futzung. 

Offenheit bedeutet aber auch, daß einfache \lege für den Trans- 
port von Daten sowohl vom Betriebssystem in die DV als auch 
umgekehrt nötig sind. Das ist u. a. erforderlich, um bereits 
existierende Software (z. B. Compiler), die nicht mit den Zu- 
.griffsroutinen der DV arbeiten können, in das Programment- 
wicklungssystem mit einzubeziehen, 


- Sicherheit: ! 


Eine effektive Programmentwicklung ist nur dann möglich, wenn 
die gespeicherten Daten gegen Verluste und Verfälschungen 
durch Hard- oder Softwarefehler geschützt sind. Dabei ist es 
für den Nutzer wichtig, daß 


. Datensicherungsalgorithmen die normale Arbeit wenig 
beeinträchtigen, 

. Datenwiederherstellung sofort nach einem Fehler 
möglich ist und 

. der Zustand der Daten nach einer Wiederherstellungs- 
maßnahme möglichst dem vorherigen Stand entspricht. 


Die herkömmlichen Verfahren zur Datensicherung auf der Basis 
von Sicherungskopien und Abzügen entsprechen insbesondere 
nicht der letzten Forderung. 


3. Interne Filestrukturen 4269 


Geht man von der Forderung nach Reorganisationsfreiheit der Da- 
ten eus, so stellt sich die DV aus der Sicht des Betriebssystens 
als ein Speicherraum der, dessen Blöcke B. mit gleicher und 
fester Länge 1 die physische Zugriffseinheit bilden. Aus der 
Sicht der Nutzer bzw. Nutzerprogramme besteht die DV aus einer 
Menge von voneinander unabhängigen Files F» deren Segmente S, 
die logische Zugriffseinheit bilden. Vereinfachend sei angenon- 
men, daß auch die Segmente gleiche unäü feste Länge besitzen, Es 
wird ein Abbildungsmechanismus B, &-» S; als Bindeglied zwischen 
physischen Blöcken und logischen Segmenten erforderlich. Damit 
kommt man zu der in Bild 1 dargestellten Speicherstruktur. 


DA cazaNaa ae 
Ver- \\ 
2eichnis Y | 
ENEENENER MT DR 
ljof-[fofrjoltjoltlololtiT] Strap 


Bild 1: Reorganisaflonsfreie Speicherstruktur 


Eine solche Grundstruktur, die typisch ist für viele DV-Inple- 
mentationen, ist jedoch sehr anfällig für Systenmfehler. Wenn 
es zu fehlerhaften Betriebssystemzuständen kommt, nachdem Da- 
ten verändert wurden, aber dieses noch nicht im Verzeichris 
vermerkt ist, so geht u. U. die Integrität der gesamten DV 
verloren. Es entstehen Fehler in der Bitmap oder in den File- 
tabellen; diese führen in der Folge zu fehlerhaften AdreßBauf- 
lösungen, so. daß Datenblöcke entweder nicht mehr erreichbar 
sind oder unzulässigerweise als frei gemeldet werden. 
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4. Datensicherheit 


4.1. Fehlerarten 


Das im folgenden vorgestellte Datensicherungsverfahren ist für 
die Behandlung folgender Fehlerarten geeignet: 


- Systemfehler (Crash): 


+. plötzliche und unvorhersehbare Beendigung aller im Rechner 
ablaufenden Prozesse, 

+. Verlust aller im Hauptspeicher befindlichen Daten einschl. | 
Puffer, 

. undefinierte Zustände der Blöcke, auf denen gerade Schreib- 
vorgänge aktiv waren, 

. kann entstehen durch Prozessorausfall, Stromversorgungs- 
ausfall usw. 


- Plattenfehler: 


. Datenverfälschung oder -verlust eines oder mehrerer Daten- 
blöcke, 

. kann entstehen durch mechanische Beschädigungen der Platten- 
oberfläche, Schmutzablagerungen, altersbedingte Veränderung 
der Magnetisierung usw. 


- Nutzerfehler: 


. vom Nutzer gewünschter oder von der DV geforderter Abbruch 
einer Speicherafugabe, 

. kann erforderlich werden durch drohende Integritätsverletzung, 
fehlerhafte Speicheranforderung usw. 


4A.2. Transaktionen 


Bei der rechnergestützten Softwareentwicklung handelt es sich 
um einen sehr datenintensiven Prozeß. Dabei wird durch die An- 
wendung einer datenverändernden Operation O von einem integren 
Datenzustand I, zu einem anderen integren Zustand 1,4 überge- 
gangen. Häufig besteht die Operation O aus mehreren Teilopera- 
tionen Ojs00.,0.. Die dıabel entstehenden Zwischenzustände sind 
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nicht notwendig integer. Wenn mit Z, (j=1,..,k-1) die Zwischen- 


zustände bezeichnet werden, läßt sich die Auflösung der Opera- 
tion O in eine Folge von Operationen wie folgt angeben: 


Zm04 (145 29=05(27), or» Zn mOg4lZynde Irygmögl2y4)> 


Als ein Beispiel sei hier eine Operation zur Änderung einer 
Baumstruktur genannt. Diese besteht i. allg. aus zwei Schritten: 


1. Änderung der Strukturinformationen, 
2. Änderung der eigentlichen Daten. 


Ein Systemfehler während der Ausführung einer der Teiloperationen 
045 ...,0, führt somit zu fehlerhaften Daten- bzw. Verzeichnis- 
inhalten. Deshalb ist es sinnvoll, zur Sicherung der Daten in 
einem PES das Mittel der Transaktion (TA) einzusetzen. Damit wird 
es möglich, solche oben beschriebenen Operationsfolgen als eine 
Binheit zu behandeln. Der zeitliche Verlauf einer TA ist in Bild 
2 dargestellt. 


Aktir-Phase 


Beginn EEE —__ Ende or TA 
80T 0, O, 0, {o. Kor Zeit 


Bild 2: Zeiflicher. Ablauf einer Transaktıon 


Der Umfang einer TA, also die zu ihr gehörenden Operationen, 
wird in den Nutzerprogrammen durch entsprechende BOT- bzw. EOT- 
Klauseln definiert. Durch die Routinen des TA-Nanagnments wer- 
den folgende Eigenschaften abgesichert: 


1. atomar - entweder ist eine TA vollständig ausgeführt 
oder gar nicht, 
2. permanent - die Ergebnisse einer TA bleiben nach EOT 
unabhängig von Fehlern erhalten. 


Außerdem erhält der Nutzer die Möglichkeit, eine TA während 
ihrer Aktiv-Phase zurückzusetzen, also den Darenauatend vor 
BOT wieder herzustellen. 
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4.3. Bereitstellung und Speicherung von Sicherungsinformationen 


Jede Maßnahme zur Datensicherung beruht auf der’ Redundanz von 
Daten. Auch zur Sicherung der TA-Eigenschaften ist es notwen- 
dig, zusätzliche Sicherungsdaten auf einem Log-File zu spei- 
chern. Das ist ein sequentieller Datenträger, der für jede TA 
folgende Informationen enthält: 


BOT-Satz | Before-Image | After-Image en) EOT-Satz 


Daten eines Segments 
vor nach 
dessen Veränderung 


Da für alle TA's ein gemeinsames Log-File benutzt wird, sind 
die Sicherungsdaten der verschiedenen TA gemischt gespeichert, 
Deshalb enthält jedes Image Identifikationsdaten mit folgendem 
Aufbau: 


Das Schreiben der Log-Daten wird vom TA-Managment realisiert. 
Damit besteht z. B. eine transaktionsorientierte Schreib- 
operation aus den Schritten: 


TAWRITE (TA-no,File-no,Segment-no,Datenadresse) 
READ (File-no,Segment-no,Adresse) Lesen des alten Seg- 
WRITELOG (TA-no,before,Adresse) mentinhalts und 
Schreiben auf Log 
WRITE (File-no,Segment-no,Datenadresse)] Schreiben der neuen 
WRITELOG (TA-no,after,Datenadresse) Daten in File und 
euf Log 


Die Sicherung der TA-Eigenschaften erfolgt durch Auswertung der 
Log-Daten nach folgendem Schema: 
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Before-Image der entspr. TA -->DV 


1. alle unvollend. TA ermitteln 
2. Before-Im. d. unvollend. TA --> DV 
3. After-Im. d. vollend. TA -->DV 


Plattenfehler|After-Image der vollend. TA -->DV 


Das Log-File kann von Zeit zu Zeit reorganisiert werden, da es 
sonst viele nicht mehr benötigte Daten enthält. Nach einem 
Crash können die Sicherungsdaten aller unvollendeten TA ge- 
löscht werden. Außerdem können die After-Images der vollende- 
ten TA auf einem Archivlog gespeichert werden, das bei Platten- 
fehlern gemeinsam mit dem aktuellen Log inspiziert werden muß. 


Eigenschaft Fehlerart 
atomar Nutzerfehler 


Systemfehler 


5. Implementation einer Datenbasis für ein PES 


© 


Für eine erste Version eines Programmentwicklungssystems 
/K082/ wurde eine Datenverwaltung entsprechend den 0. g. 
Grundsätzen implementiert. Sie ist für den Einsatz im Be- 
triebssysten OS/ES gedacht, kann jedoch bei Bedarf auch auf 
anderen Rechnern installiert werden. Als Implementations- 
sprache wurde N-PASCAL /BK82/ gewählt, die eine Erweiterung 
von PASCAL um wesentliche Teile des Nodulkonzepts von MODULA-2 
darstellt, 


5.1. Implementation der Speicheralgorithmen 


Es wurde das Filesystem PROFILE /Su84/ realisiert, das auf 
den im Abschnitt 3 beschriebenen Grundstrukturen beruht. Die 
vom UNIX bekannten Funktionen, wie CREATE, OPEN, READ, WRITE 
usw., werden dem Nutzer bzw. WMutzerprogranmm als Satz externer 
Routinen im Sinne von PASCAL zur Verfügung gestellt. Um die 
Portabilität und die Offenheit des Systems zu gewährleisten, 
wurde eine Schichtenarchitektur (Bild 3) implementiert. 

Soll das System auf einem anderen Rechner installiert werder, 
so muß der ASSENBLER-Modul REALACC ausgetauscht bzw. über- 


Lew 2 


Nutzer programm 


Routinen der 
FILESTORAGE File verwaltung 
 BUFACC Pufferverwaltung 
Inter faceroufinen 


um Betriebssystem 


Betriebssystem 


Bild 3 : Schichtenarchitektvor von PROFILE 


arbeitet werden. Dabei wird lediglich eine Direktzugriffsmög- 
lichkeit auf externe Daten mit eines Blockgröße von 512 Byte 
gefordert. 

Der Modul BUFACC kann ganz entfallen, wenn das aufgrund zu 
geringen verfügbaren Speicherplatzes erforderlich ist. Dies 
wird durch gleiche Anschlußbedingungen sowohl für REALACC als 
auch für BUFACC ermöglicht. 3 


5.2. Implementation des TA-Managments 


Der im Abschnitt 4 beschriebene Datensicherungsalgorithmus 
auf der Basis des Transaktionskonzepts wurde als ein Nutzer- 
programm von PROFILE implementiert. Dadurch waren keine Ein- 
griffe in die Filesystemverwaltung erforderlich (Bild 4). 
Die PROFILE-Funktionen werden vom Modul TRANSACT verwendet, 
um das TA-Managment zu realisieren. Der Nutzer hat denn nur 
noch mit Hilfe von TRANSACT Zugang zu den Filesystemdaten, 
der ihm durch transaktionsorientierte Operationen ermöglicht 
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Nufserprogramm 


| 
411317 Filssystemroutinen 


PROFILE 


Bild4 : Verbindung Filesystem - TA-Managmenf 


wird. Zusätzlich werden folgende Funktionen angeboten: 


TAOPEN - Eröffnen einer Transaktion. 

TACLOSE - Abschließen einer Transaktion 

TAABORT - Abbruch einer Transaktion 

RESTART - Wiederanlauf von TRANSACT nach Systemfehler, 


Weitere‘ Funktionen zur Datensicherung bei Plattenfehlern sowie 
zur Reorganisation des Log-Files sind in Vorbereitung. 
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jas bildschirmorientierte Simulationssystem TOMAS - 
tand der Entwicklung und erste Erfahrungen bei der Anwendung 
uf Prozesse der Elektronikindustrie 


1. Stand der Entwicklung von TOMAS/ES 


Das Simulationssysten TOMAS (Technology Oriented Modelling 
And Simulation) wurde für die Modellierung und Simulation 
'zeit- und zustandsdiskreter technologischer Prozesse für 
Technologen als Fachnutzer geschaffen. Es ermöglicht die 
effektive Erarbeitung von Projekt- und Rationalisierungs- 
varianten solcher Prozesse. 

Mit der Entwicklung von TOMAS wurden im wesentlichen folgende 
drei Grundprobleme gelöst, die eine unmittelbare Anwendung 

| von TOMAS durch Technologen ermöglichen: 


1. Ein prozeßorientiertes Modellierungskonzept gestattet 
die Erfassung und Widerspiegelung komplexer Zusammen- 


hänge eines Realprozesses, a 


2. Von .der methodologischen Gestaltung her wird dem Fach- 
nutzer ein seiner Denkweise entsprechendes Prozeßstruk- 
turlerungskonzept in die Hand gegeben, das ihn von Fre- 
gen der mathematischen Formalisierung und Algorithmie- 
rung prozeßrelevanter Modellbestandteile und deren 
rechentechnischer Umsetzung (Programmierung) vollstän- 
dig entlastet. 


3. Ein interaktives Zugangskonzept zum System TOMAS auf 
umgangssprachlichem Niveau unterstützt den Nutzer in 
seiner fachgebletsbezogenen Denkweise, führt ihn weit- 


gehend bei der Modellierung und ermöglicht Experimente 
am Modell. 


Das grundsätzliche Konzept von TOMAS ist u. a. in /1/, /2/ 
beschrieben, 


Charakteristisch ist, daß dem Nutzer für den Bau des Prozeß- 
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modells vorgefertigte Bauste ne angeboten werden, von denen 
Jeder einen typischen Teilprozeß diskreter technologischer 
Prozesse algorithmisch nachbildet. 

Der Modellierungsablauf gestaltet sich wie folgt: 


1. Strukturierung des zu simulierenden Prozesses im Hin- 
blick auf die verfolgten Zielkriterien und unter Beach- 
tung der in den angebotenen Bausteinen fixierten Ab- 
läufe 


2. Dialogeingabe des im ersten Schritt entstehenden Pro- 
zeßmodells in den Phasen 
- Struktureingabe 
- Modellierelemente- (Baustein-) Zuweisung 
- Parameterinitialisierung 


Modellmanipulationen in struktureller und funktioneller Sicht 
sowie Aspekte der Experimentplanung (Ergebnisgewinnung, Zeit- 
steuerung usw.) sind ebenfalls dialoggestützt einfach angeb- 
bar. 

Die aktuelle Version TOMAS/ES-1.2 ist noch vorrangig auf die 
Nachbildung technologischer Basisprozesse der Großserien- und 
Massenfertigung orientiert, wobei Aspekte der Fertigungssteu- 
erung nur implizit in gewissem Umfang realisiert sind. 
Gegenwärtig entsteht die Version TOMAS/ES-2.0, die durch fol- 
gende neue wesentliche Merkmale gekennzeichnet int: 


1. Einbeziehung der Pertigungssteuerung (im Sinne eines 
automatisierten flexiblen Fertigungsabschnitts) in den. 
vorgefertigten Bausteinvorrat 


2. Möglichkeit zur automatischen Generierung eines Modell- 
ansatzes aus betrieblichen technologischen Daten. 


3. weitere Strukturierung des Zugangssystems in methodo- 
logischer und funktioneller Hinsicht 


Erste Erfahrungen dazu werden zu Beginn des Jahres 1986 vor- 
llegen. 


2. Erste Erfahrungen bei Bei randnk von_TOMAS 

Die Untersuchung komplexer technologischer Trozesse ist infolge 
ihrer zunehmenden Verflechtung oftmals nur mit Hilfe der Simu- 
lation möglich. Der dazu erforderliche hohe Programmieraufwand 
kann durch die Nutzung geeigneter Simulationssysteme reduziert 
werden, wobei besonderer Wert darauf gelegt werden sollte, den 
Technologen zur direkten Nutzung dieser Systeme zu befähigen. 


TOMAS bietet aufgrund seines dlialogorientierten Konzepts diese 
Möglichkeit; der Vorrat an modelllierenden Elementen (Bausteinen) 
gestattet die Nachbildung von Großserienfertigungsprozessen 

am Bildschirm und deren Simulation im Stapelbetrieb. Die Vor- 
teile für den Anwender bestehen - insbesondere gegenüber an- 
deren Simulationssystemen -— in der Führung des Nutzers durch 
den Rechner und der damit verbundenen sofortigen Prüfung der 
Eingabedaten. Durch eine anwenderfreundliche Gestaltung der 
Dialogbilder werden fehlerhafte Reaktionen weitgehend vermie- 
‘den. Das gilt auch für kompliziertere Eingaben, z.B. von empi- 
rischen Verteilungsfunktionen, die wertepaarweise bereitge- 
stellt werden müssen. Rs 


Modelländerungen sind ebenfalls im Dialog möglich und gestat- 
ten demit die Untersuchung von Varianten, wobei sowohl die 
Struktur des Modells als auch die Eingabedaten variiert werden 
können, Zusätzlich zur Bildschirmausgabe werden alle für das 
Modell relevanten Eingaben auf dem Drucker protokolliert, um 
das Simulationsmodell zu dokumentieren. Die Form dieser Doku- 
mentation kann noch nicht alle Wünsche bezüglich Übersicht- 
lichkeit befriedigen, an einer Verbesserung wird z.2. gear- 
beitet. Weitere Forderungen, die sich aus der Arbeit mit dem 
System in der Erprobungsphase. ergaben und z.B. die Modelliden- 
tifizierung, die Eingabe der Simulationsdauer u.a, betreffen, 
wurden bereits realisiert. 


In der Erprobungsphase für die Version TOMAS 1.0 wurden Fer- 
tigungsprozesse der Elektrönikindustrie untersucht. Da für 
solche komplexe Prozesse in zunehmendem Maße dezentrale Daten- 
vererbeitungsanlagen für die Steuerung eingesetzt werden, 
stand hierbei nicht die Naohbildung des Materialflusses im 
Vordergrund, sondern die Simulation des Informationsflusses, 
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Der Informationsflüuß stellt praktisch das Bindeglied zwischen 


Prozeßanalyse und Prozeßsteuerung dar. Seine Durchdringung 
ist die Voraussetzung für die Gestaltung eines leistungsfähl- 
gen Informationssystems unter Einsatz eines Prozeßrechner- 
systens. . 


In /3/ wurde festgestellt, daß sich TOMAS auch für die Model- 
lierung von Informationsflüssen eignet. Die für das Inforne- 
tionssystem erforderlichen Datenmeldungen (z.B. Posteneröff- 
nungsmeldung, Teilschrittmeldung, Postenabschlußmeldung), die 
im Originalsystem über Terminals eingegeben werden und eine 
Rechnerelementestruktur zum Zwecke der Verarbeitung durchlau- 
fen, werden in TOMAS durch Operanden nachgebildet und bewegen 
sich durch eine Struktur von modellierenden Elementen. Dabei 
werden z.B. mittlere Auslastungen von Terminals und mittlere 
sowle maximale Längen der davorliegenden Warteschlangen für 
mehrere Modellvarianten, die sich durch verschiedene Vertei- 
lungen für Bearbeitungs- und Reparaturzeiten unterscheiden, 
ermittelt. Diese Ergebn&sse machten es möglich, die bisherige, 
nur auf Erfahrungen beruhende Einsatzvorbereitung für das Pro- 
zeßrechnersystem quantitativ besser zu erfassen und Maßstäbe 
dafür zu gewinnen, welcher Umfang der Meldungen mit einer 
bestimmten Gerätekonfiguration noch zufriedenstellend verar- 
beitbar ist. ' 


Abschließend sei bemerkt, daß die Lösung dieser Problematik 
mit Hilfe von TOMAS bereits in der Erprobungsphase dieses 
Simulationssystems erfolgen konnte, daß die Einarbeitungszeit 
des Anwenders relativ kurz war und daß auch wertvolle Hinweise 
für die Erhöhung der Nutzerfreundlichkeit von TOMAS gewonnen 
wurden. 
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DIALOGSYSTEM DIAL FÜR PROGRAMMIERER, TECHNOLOGEN UND ANWENDER 


1. Bildschirmserätssystem EC 7920 


Das Gerütesystem EC 7920 ist ein universelles alphanumerisches 
Kommunikationssyasten, das an ESER-Anlagen angeschlossen werden 
kann. Zum Bildschirmgeräitesystenm EC 7920 gehören das Bild- 
schirngerät EC 7927 mit Tastatur und Selektierstift, der Druk- 
ker EC 7934, die Lokalsteuereinheit EC 7922 und die Fernsteuer- 
einheit EC 7921. Die Lokalsteuereinheit wird direkt an einen 
Kanal der Zentraleinheit angeschlossen. Zwischen der Fern- 
steuereinheit und einen Multiplexsteuergerät (MPDL) wird die 
Übertragungstechnik für Datenfernverarbeitung geschaltet, Das 
Multiplexsteuereerät wird an einen Multiplexkanal der Zentral- 
einheit angeschlossen, An ein Multiplexsteuergerät können auch 
mehrere Fernsteusreinheiten Über jeweils eine Übertragungstech- 
nik angeschlossen werden, Sowohl an einer Lokal. als auch an 
einer Fernsteuereinhelt können bis zu 32 Bildschirnmgeräte oder 
Drucker des Systens EC 7920 in beliebiger Kombination ange- 
schlossen werden, 

‚Der Bildschirm des Gerätes EC 7927 ist in 24 Zeilen und 80 
Spalten zur Darstellung jeweils eines alphanwmerischen Zei- 
chens eingeteilt. Ir allgemeinen wird vom Program ein Bild 
vorgegeben, welches der Bediener mittels Tastatur verändert, 
Das vom Programı vorgegebene Bild kann formatisiert sein, Das 
heißt, es kann in Felder mit folgenden Eingenschaften eingeteilt 
sein; 
- ungeschützt oder geschützt, 

- numerisch oder alphanumerisch, 

- normal hell anzeigbar, -intensiv anzeigbar oder nicht anzeig- 

bar und 

- mit Selektierstift selektierbar oder nicht, 

Dieses Feldkonzept der Gerätetechnik bletet die Möglichkeit, 
anwenderfrewndliche Dialosprogramme zu entwickeln, Das Dialoe- 
system DIAL stützt sich auf dieses Feldkonzept und ist sonit 

für eine andere Gerätetechnik nicht nutzbar, j 
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2. Komponenten von DIAL 
PORG: Diese Komponente ist die dialogfählge Variante des Pro= 
grammsystens PORG zur Verwaltung und Pflege von Progranmdaten 
und. enthält Funktionen zum: 
- Darstellen, Zufligen und Modifizieren von Quelltexten 
- Darstellen des Inhaltsvorzeichnisses von Bibliotheken und 

des Operativspeichers 
- Löschen von Bibliotheksbostünden bzw, Tabellen 
- Aufruf von (Stapel-)Operationen dos Programmsyatens PORG 

wie MODIFY, COPY, LIST, PREPARE usw. 
LIST: Mit dieser Komponente besteht die Möglichkeit, Druck- 
listen darzustellen und Zeilen der Druckliste zu modifizieren, 
Die Drucklisten nlissen sich hierzu in einem speziell organi- 
sliorten Tabellenspeicher befinden, Für spezielle Drucklisten 
bzw. spoziolle Anwendungsfälle können geeignete Formate zur 
Darstellung der Drucklisten generiert werden, Neben der be- 
reits erwähnten Funktion enthält die Komponente noch weitere 
Funktionen zums 
- Laden. von Druoklisten in den Tabellenspeicher 
- Zurflokspeichern von Drucklisten aus den Tabellenspeicher 
- Ausgabe von Drucklisten auf Schnelldrucker 
- Ausgabe von Drucklisten auf einem EC 7920-Drucker 
- Darstellen des Inhaltsverzeichnisses des Tabellenspeichers 
= Löschen von Druoklisten aus dem Tabellenspeicher, 
EXEC: Hiermit wird der Aufruf und die äbarbeitung von Progran- 
gen gesteuert, die in Stapelbetrieb als Jobstep laufen, Durch 
eine goeelgmete Generierung kann der Aufruf spezieller Program- 
ne bzw. Progranmklassen (z. B. Assembler, Progranmverbinder, 
Dienstprograzmme, bestirmte Anwenderprogramme) besonders un- 
terstützt werden, 
JOB: Der Datenendplatzumutzer kann mit dieser Komponente Jobs 
einschließlich Jobbeschreibung auf einer im Rechenzentrum zen- 
tral angelegten Jobsammeldatei abspeichern, d. h. an den Ar- 
beitsvorbereiter absenden, Der Arbeitsvorbereiter verwaltet 
diese Jobsammeldatei und veranlaßt die Abarbeitung der auf 
dieser Datei eingegangenen Jobs. Der Arbeitsvorbereiter be- 
stimmt hierbei die Reihenfolge und die EDVA für die Abarbei- 
tung der Jobs, 
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AV: Diese Komponente ist das Hilfsmittel für den Arbeitsvorbe- 

reiter zur Verwaltung der Jobsammeldatel, für das Umsetzen der 

Jobs in die Warteschlangen der EDVA und zur Steuerung von Ilie- 

derholläufen, In die Jobsammeldatei werden auch generierte Jobs 

der Stapelverarbeitung für Massendatenverarbeitunz eingespei- 
chert und somit zur Abarbeitung durch den Arbeitsvorbereiter 
mit Hilfe dieser Komponente veranlaßt, 

BATCH: Die Anwenderprogramme (Operationen), die im Stapelbe- 

trieb unter dem einheitlichen Steuerrahmen DATCH laufen, kön- 

nen im Dialogbetrieb mit Hilfe der Komponente BATCH aufgeru= 
fen und abgearbeitet werden, Desweiteren können dialogsführen- 
de Anwenderoperationen aufgerufen werden, wie z, B,: zur Dam 
stellung und Hodifizierung von Referenzspeicherdaten von Ar 

wendungsfällen und zur Darstellung und Modifizierung von di- 

rektgespeicherten Massendaten, 

USER: Diese Komponente ist eine Erweiterung der Komponente 

BATCH, die folgende Möglichkeiten zusätzlich enthält: 

- Steuerung der Auflösung und Abarbeitung mehrstufiger Mak= 
ros, die jeweils eine Folge von Anwenderoperationen reprä- 
soentieren 

- Steuerung von vorbereiteten Dialogabläufen (Modifizierung 
und Abarbeitung einer Folge von Makros) 

- Generierung von Stapeljobs der Massendatenverarbeitung 


3. Nutzung von Datenendplätzen 


Die Komponente JOB wird von allen Datenendplätzen (DEP) gm 
nutzt, 

Programmierer: Der DEP "Programmierer" besteht vor allem in 
der Nutzung des TSO-Kommandos TEST (zur Testung von Assemb- 
lerprogrammen), der DIAL-Komponenten PORG (zur Programmdaten- 
pflege), iXEC (zum Aufruf des Programmverbinders, des Assemb- 
lers und des Superzaps-Programms) und LIST (zum Darstellen und 
Drucken von Protokollen) sowie des TSO-Kommandös SUBMIT (zum 
Absetzen von llintergrundjobs), 

Pro jektant: Vom Projektant werden vor allem die DIAI-Konponen- 
ten PORG (zur Projektdatenpflege), DATCH und USER (zum Testen 
von Projekten und zum Einrichten wnd Erproben von Anwendunes- 
fällen) und LIST (zum Darstellen und Drucken von Protokollen 
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sowie zum Darstellen (Überprüfen) der vom Projekt erzeugten 


Ergeinislisten) sowie die TSO-Funktion SUBMIT, 

Arbeitsvorbereiter: Der DEP "Arbeitsvorbereiter" besteht in 

der Nutzıme der Komponente AV, Außerhalb der TSO-Betriebszeit 

wird DIAL im BTAM.Betrieb genutzt, Für den Ausfall der Bild- 

schirmtechnik eibt es eine Stapelversion zur Verwaltung der 

Jobsammeldatei, 

Durchlaufbetreuer: Zur Bearbeitung von Aufträgen der Massenda- 

tenverarbeitung werden Komponenten USER (zur Jobgeneriermg), 

EXEC (zum Aufruf von Dienstprogrammen und zur Jobgenerierung) 

und LIST (zum Darstellen und Drucken von Protokollen) genutzt. 

Anwender: Die Aufgaben der einzelnen Anwender sind sehr unter 

schiedlich und, auch die Amrendung der EDV ist sehr unter- 

schiediich, Sie reicht von der Nutzung eines einzigen relativ 

starren Projektes bis hin zur Nutzung von mehreren komplexen 

und flexiblen Projekten, Somit ist auch die Nutzung von DIAL 

bei den Anwendern weitaus wmterschiedlicher als bei den bisher 

beschriebenen DEP, Vom Anwender werden die Komponenten USER, 

BATCH, EXEC, PORG und LIST für folgende Tätigkeiten genutzt: 

- Eingabe und Pflege von Listmusterabrufen zur: Erzeugung von. 
Plandokumenten und anderen Ergebnisiisten 

- Pflege von Nomenklaturen im Referenzspeicher 

- Pflege von Formelpaketen im Referenzspeicher 

- Datenpflege (bei geringem Umfang) 

- Durchführung von Rechnungen (bei geringen Umfang) 

- Erzeugung von Drucklisten (bei geringem Umfang) 

- Darstellung von Drucklisten mit statistischen Daten 

- Überprüfung der Ergeimislisten von Modellberechnungen 

- Korrektur von Plandokumenten und anderen Ergebnislisten 


&, Prinzip der Steuerung und der Dialogführung von DIAL 


Das Dlalogsgten DIAL besteht aus dem Steuerrahmen und den vorge- 
stellten Komponenten, Im Steuerrahmen und ir allen Kompönenten 
von DIAL ist ein einheitliches Prinzip der Dialogführung und der 
Bildgestaltung realisiert, Den Dialog kaun man als Struktur In- 
terpretieren, wobei die einzelnen Punkte ein Bild repräsentieren, 
In Abbildung 1 ist ein sehr vereinfachtes Schema der Dialogstruk- 
tur dargostellt, 


Abbildwme 1: 4-85 


Auswahl _der 
Komponente 


Auswahl der 
Funktionen 


Auswahl der Daten, 
Auswahl bzw, Einga- 
be von Paranetern 
und bei nicht dia- 
logeführenden Funk- 
tionen 1) 
Ausführung der 
Funktionen 


Datendlalog 
(Darstellung und/ 
oder NModifizierung 
von Daten) 


Die Tasten zur Adhtungsunterbrechung finden hierbei weitestgehend 

einheitliche Verwendung. 

Die Nutzung von DIAL ist in den fölgenden drei Betriebsarten 

nöglich: 

- Simulations-Betrieb: zur Entwicklung bzw. Weiterentwicklung 
von DIAL ohne Inanspruchnahme der Gerätetechnik EC 7920 

- BTAM-Betrieb: für den Einsatz weniger Bildschirmgeräte 
(max, 5). im Nahanschluß geeignet 

- TSO-Betrieb: für den Einsatz einer größeren Anzahl von 
Bildschirngeräten und flir den Einsatz von fernangeschlosse- 
nen Bildschirmgeräten geeignet, Für diese Betriebsart ist 
der Einsatz des Teilnshmersystems TSO eine Voraussetzung, 


5. Möglichkeiten und Hilfsmittel zur Entwicklung bzw. Weiter- 
entwicklung von DIAL 


Zunächst gibt es die eigens für DIAL entwickelte Zugriffsmetho- 
de QDIS, Mit QDIS wird neben den Zugriffen zum Blldschirmgerät, 
die Pufferverwaltung, die Umrechnung der Bildadressen und die 
Analyse der Eingabepuffer unterstützt, Damit entfallen für den 
Anwendimgsprogrammierer die immer wiederkehrenden Routinearbei= 
ten, Durch die Nutzung von QDIS kann man auch unabhängie von ' 
der Betriebsart (s. Punkt 4,) programmieren. 
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Weiterhin gibt os das Hilfsmittel DIAI-H, Das Hilfsmittel 


DIAI=-1i Ist darauf serichtet, daß eine einheitliche Gestaltung 
des Dialogs (Pialogstruktur, einheitliche Tastenbelegung usw, ) 
gewährleistet ist, 

während QDIS eine Zugriffsmethode ist — einem READ=-WRITE- 
Niveau entspricht - entspricht DIAL-H dem Charakter nach einem 
Programmlersysten, Jedoch unterstützt DIAL-H nur die Arbeit mit 
dem Bildschirm und nicht die Arbeit mit irgendwelchen Speichern, 
Somit müssen die Komponenten von DIAL ihre Speicherarbeit zwar 
selbst organisieren, aber DIAL-H ist universell einsetzbar, 


. 
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Ein Beitrag zur Modularisierung beim Softwareentwurf 


1. Einleitung 

Ein wichtiges Prinzip bei der Softwareentwicklung ist die 
Modularisierung geworden. 

Wie in den Technikwissenschaften, so bringt auch in der Soft- 
wearetechnologie die Arbeit mit Moduln viele Vorteile für die 
Realisierung und Nutzung komlexer Systeme. 

Entsprechende Konzepte zum Aufstellen von modularer Software 
werden in modernen Programmiersprachen weitestgehend berück- 
sichtigt (2.3. NODULA2, ADA). 

Es besteht somit die Aufgabe, für ein zu realisierendes Soft- 
wareprodukt einen modularen Programmentwurf zu erstellen. Die 
Festlegung der modularen Programmstruktur eines Softwarepro- 
dukts muß bereits während des Softwareentwurfs mit den zur 
Verfügung‘ stehenden Informationen erfolgen. 

In der Literatur sind ausführlich das Aufstellen eines Systen- 
entwurfs und die Anforderungen an eine modulare Beschreibung 
dokumentiert (z.B. in /KIMM79/, /SCHN79/). Wie ausgehend von 
einem Systementwurf eine modulare Programmstruktur erstellt 
werden kann, ist aber in der Literatur nur wenig ausgeführt. 
Arbeiten zur Analyse des Softwaresystementwurfs (vgl. /HORN85/) 
zeigen, daß ein Systementwurf unabhängig von einer gewählten 
Softwareentwurfsmethode und der demit verbundenen Form der 
externen Beschreibung als eine Struktur von Aktionen und Daten- 
elementen mit Beziehungen zwischen diesen dargestellt werden 
‚kann. 

Der Prozeß der Modularisierung ist eine Transformation der 
Struktur des Systementwurfs in die Struktur des Programment- 
wurfs. Sie erfolgt in der Regel dadurch, daß eine Abgrenzung 
und bzw. oder eine Zusammenfassung von Elementen zu Teilsystemen . 
des Systementwurfs nach bestimmten Kriterien vorgenommen wird. 


Diese sind von speziellen Hützsränroregen und der kon- 
kreten Basismaschine abhängig. 

Nachfolgend soll ein Ansatz vorgestellt werden, wie diese 
Trensformation realisiert werden kann. 

Entsprechend der erläuterten Strategie kann ein rechnerge- 
stütztes Werkzeug zur Verfügung gestellt werden, das bestimmte 
Arbeiten bei der Ableitung von Moduln unterstützt. 


2. Ableitung von Moduln aus einem Systementwurf 
2.1. Darstellung des Systementwurfs 
Der Systementwurf kann als ein formales Systen beschrieben 
werden: 

SE=( ES, Ropl 
Die Systemelemente ES werden durch die Mengen der Systemaktionen 
und Datenelemente bestimmt: 


25- {a, >} 


Die Beziehungen zwischen den Elementen werden durch Ras ange- 
geben: 
Rp“ (Rssır Asp’ Ron5} 


Raps D xA - Aktion a, benötigt Datenelement d, 


i 
e ö 
Ropz> A xA Aktion a; folgt auf Aktion a, 


Ropo= AxD - Aktion a, erzeugt Datenelement d, 


Durch Zusammenfassen von Elementen des Systementwurfs lassen 
sich Teilsysteme abgrenzen: 


TS=( EIS, Rng) 


Die Auswahl der Elemente und der Beziehungen zwischen diesen 
für das betreffende Teilsystem wird dabei durch ein Prädikat 


bestimmt: 
BIS Tas» Das | Ins } 
= fr P 
Ans [ ing | Prs 


Der Systementwurf kann somit auch durch eine Struktur von Teil- 


A 
4-89 
systemen und den Beziehungen zwischen diesen angegeben werden: 
TSS=( TS, Rss) 
Die Beziehungen zwischen den Teilsystemen (Rngg) sind eine 
Menge von Relationen, die bestimmt sind durch die Relationen 
zwischen den Elementen, die verschiedenen Teilsystemen ange- 


hören; n 


Ras U ( Rys, etöns € VElRz, )Aetang € NBRzs,) ) 
i=1 


2,2. Darstellung der modularen Programmstruktur 


Die modulare Programmstruktur kann analog dem Systementwurf als 
ein formales System dargestellt werden: 


PS=( EPS, Rpg) 


Als Elemente dieses Systems treten Modulbeschreibungen und die 
Beschreibung der Umwelt auf: 


EPS= (1, u} 
Für die Darstellung der Modulbeschreibungen wird die Modul- 
definition nach /BALZ78/ zu Grunde gelegt: 
"Ein Modul ist ein Untersysten, das folgende Eigenschaften be- 
sitzt: 
1. Bereitstellung einer Funktion oder einer Datenabstraktion; 
2. Kontextunabhängigkelt 
Die Kontextunabhängigkeit beinhaltet, daß. der Modul von der 
Modulumgebung unabhängig entwickelbar, übersetzbar, testbar 
bzw. verifizierbar, wartbar und verständlich ist, 
3. Spezifizierung durch Schnittstellenbeschreibung; 
4. Niedrige Schnittstellenkomplexität." 
Die Schnittstellenbeschreibung entspricht der genannten Modul- 
beschreibung. Diese enthält alle relevanten Informationen über 
den Modul, die der Modulumgebung bekannt sein müssen. So gehören 
dazu unbedingt die Angaben, welche Ressourcen der Modulumgebung 
bereitgestellt werden und welche Ressourcen von der Nodulum- 
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gebung benötigt werden. Eine Modulbeschreibung kenn somit 
els ein Tupel von Informationen Über einen lodul betrachtet 
werden. 
Entsprechend der Moduldefinition treten Moduln vom Typ 
"Punktion" und "Abstrakte Datenstruktur" auf. Eine ausführ- 
liche Darstellung der liodultypen ist in /WINK85/ enthalten. 
Eine analoge Beschreibungsform gilt für die Umelt. 


Die Beziehungen zwischen den Elementen der Programmstruktur 
werden beschrieben durch: 


Rpg® (R2s} ’ Rose } 
G zu ’ 
Rpg; >15 x HM, Kodul Mm, benutzt Modul m. 


RpgoS N 2:0; - Nodul m, steht mit einem Umwelt- 
element u, in Beziehung 


Neben diesen Beziehungen zwischen den Elementen besteht die 

Forderung nach einer baumartigen Struktur. Da keine weiteren 
Einschränkungen über die Nutzungsrelation bestehen, kann die 
modulare Programnstruktur als eine irreflexive Halbordnungs- 
relation betrachtet werden. Durch Klassenbildung der Moduln 

können Hierarchieebenen eingeführt werden. 


2.3, NModularisierungsstrategie 

Zur Herleitung von NModuln müssen die verschiedensten Kriterien 

entsprechend der Noduldefinition sowie der Basismeschine beachtet 

werden. Dazu zählt: 

- Realisierung von datenstrukturunabhängigen Moduln, 

- Erzielung einer Kontextunabhängigkeit durch eine hohe innere 
Festigkeit und geringen Datenaustausch zwischen den Moduln, 

- Aufbau von Moduln mit abgegrenztem Funktionsumfang und ent- 
sprechender minimalen Schnittstellenkomplexität, 

- Beachtung statischer und dynamischer Realisierungseigen- 
. schaften wie Modulgröße, Speicherbedarf, Laufzeit, Aufruf- 
häufigkeiten usw. 

Je nach lienge der vorliegenden Informationen kann ein nutzer- 
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spezifischer Programmentwurf erstellt werden. Dabei können, aus- 
gehend von den verwendeten Informationen und der Priorität der 
genannten Kriterien, verschiedene Modularisierungsstrategien 
engewendet werden. Mittels einer entsprechenden Bewertung des 
erstellten Programmentwurfs kann die für den Nutzer optimale 
Variante ermittelt werden. | 
Bei dem Aufstellen einer modularen Programmstruktur auf der 
Grundlage der mit dem Systementwurf bereitgestellten Infor- 
mationen kann nur ein Teil der wichtigen Kriterien beachtet 
werden. Angaben die die Realisierung des lioduls betreffen, 
liegen nicht vor. Da erst die Moduln durch Abspalten von Teil- 
systemen aufgestellt werden sollen, können auch noch keine Aus- 
sagen über Beziehungen zwischen den lioduln getroffen werden. 
Diese ergeben sich erst mit der Formullerung der Moduln. 
Es wird davon ausgegangen, daß im Vordergrund die Forderung 
nach logisch in sich abgeschlossenen Noduln zur Erzielung einer 
Kontextunabhängigkeit steht. 
Aus dem Systementwurf sind die Beziehungen zwischen den Systen- 
elementen ersichtlich. Es können deshalb solche Systemteile zu 
Teilsystemen zusammengefaßt werden, die enge Beziehungen be- 
sitzen und somit als logisch abgeschlossene Einheit eine hohe 
innere Festigkeit aufweisen. Gleichzeitig ergibt sich dereus, daß 
die Beziehungen zwischen den so entstandenen lioduln auf ein !!ini- 
mum reduziert werden. Werden die abgegrenzten Teiilsystenme als 
Moduln mit einem "gültigen!" Kodultyp eufgestellt, wird weiterhin 
die Datenstrukturunabhängiskeit der Moduln erreicht, 
Grundlage der Bestimmung der Teilsysteme ist die Formulierung 
eines Prädikats, anhand dessen notwendige 3eziehungen zwischen 
den Elementen gefordert werden. 
Zur Darstellung der inneren Festigkeit sind in /BALZ82/ ver- 
schiedene Bindungsarten beschrieben. Je nach Stärke dieser Bin- 
dungen werden folgende Bindungsarten unterschieden, deren 
Festigkeit in der Reihenfolge der Aufzählung zunimmt: 
- zufällige Bindung 
- logische Bindung \ 
- prozedurale 3indung 
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- kommunikative Bindung 


- sequentielle Bindung 

- informale Bindung 

- funktionale Bindung. 

Zur Erläuterung der Bindungsarten und für die Bestimmung der 
Prädikate für die entsprechenden Teilsysteme sei auf /WINK85/ 
verwiesen, j 

Untersuchungen zeigten, daß nur die vier stärksten Bindungen für 
die sinnvolle Bildung von Teilsystemen in Frage kommen. Die rest- 
lichen schwächeren Bindungsarten garantieren nicht die logisch 
abgeschlossene Einheit der entstehenden Moduln, da nur wenig Be- 
ziehungen zwischen den Systemelementen bestehen würden, Eine 
Ausnahme bildet die zufällige Bindung. Für alle Elemente des 
Systementwurfs, die nach erfolgter Abgrenzung von Teilsystemen 
wegen zu schwachen Beziehungen zu anderen Systemelementen noch 
nicht mit erfaßt wurden, können zufällige Beziehungen zur Bil- 
dung der Moduln benutzt werden. 

Folgendes Beispiel soll das Prinzip der Modularisierung zeigen. 
Zur Darstellung der Aktionen werden Kreise und für die Daten- 
elemente Rechtecke verwendet. 

Als Ausgangsstruktur liegt die Struktur des Systementwurfs vor 
(1). Auf diese Struktur lassen sich notwendige Beziehungen für 
zwei Bindungsarten anwenden. Erstens eine sequentielle Bindung 
(2) und zweitens-eine kommunikative Bindung (3). Zum Schluß 

kann aus den verbleibenden Elementen noch ein Teilsysten ge- 
bildet werden (4). 


(1) 
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Neben dem Abgrenzen von Teilsystemen auf der Grundlage der 

ausgewählten Bindungen sind weitere Forderungen zu beachten. 

Zum Aufstellen der beschriebenen modularen Programstruktur muß 

die geforderte Aufrufrelation eingehalten werden. Dies bedeutet, 

daß die Beziehungen der Teilsystenme untereinander beachtet wer- 
den müssen, damit zwischen den aufgestellten Moduln eine 
hierarchische Aufrüfrelation entsteht. Dazu gehört die Fest- 
legung der Datenelemente, die der Kommunikation zwischen den 

Teilsystemen dienen und die entsprechende Zuordnung zu einem 

Teilsystem. Es bedarf außerdem der Formulierung eines Topmoduls, 

der alle von der Umwelt ausgehenden Systemaktivierungen reali- 

siert. 

Da die zur Modularisierung benutzten Bindungsarten unterschied- 

liche innere Festigkeiten der Moduln gewährleisten, sollte immer 

die maximal mögliche Anzahl von Teilsystemen der jeweils mög- 
lichen stärksten Bindung abgegrenzt werden. 

Ein Algorithmus für die Modularisierung läßt sich so formulieren, 

daß zyklisch Teilsystem für Teilsystem, immer mit höchstmög- 

licher Bindung, abgegrenzt wird. Die Abgrenzung geschieht in 
der Form, daß Cie die Bindung realisierenden Elemente und ent- 
sprechende Parameter zur Teilsystemumgebung aus dem Systement- 
wurf gestrichen werden. Gleichzeitig wird mit ihnen eine Modul- 
beschreibung als Element des modularen Entwurfs aufgebaut, Zum 

Abschluß muß zusätzlich eine Beschreibung eines Topmoduls aufge- 

stellt werden. 

Das Streichen der Elemente. eines Teilsystems im Systementwurf 

bedeutet dabei: = 

- Bildung der Differenzmenge zwischen den im System enthaltenen 
Elementen und den im betreffenden Teilsystem sowie als Parame- 
ter berücksichtigten Elementen. 

- Eintragen entsprechender Vermerke in den Systementwurf über 
die Elemente, die bereits in Teilsystemen angelegt sind, aber 
noch weitere Beziehungen zu anderen Systemelementen aufweisen. 

Somit ist gewährleistet, daß nach jedem Abgrenzen eines Teil- 

systems ein aktueller Systementwurf vorliegt. 
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Die im Ergebnis der Nodularisierung vorliegende Struktur kann 
nach den verschiedensten Gesichtspunkten bewertet werden. So 
z.B. nach: 

- durchschnittliche Datenkopplung zwischen den Moduln, , 

- Anzahl der Moduln mit zufälliger Bindung, 

- durchschnittliche Schnittstellenbreite, 

- Angaben Zur Metrik der Struktur, 
Je nach den erhaltenen Bewertungsaussagen kann die modulare 
Struktur modifiziert werden bzw. kann die Modularisierung in 
einer änderen Reihenfolge der Anwendung der Bindungsarten vor- 
genommen werden, 


3. Werkzeug zur Nodularisierung 


Innerhalb der Arbeiten zur automatengestützten Programmentwick- 
lung soll ein Werkzeug geschaffen werden, welches die vorge- 
stellte Modularisierungsstrategie unterstützt. 
Dieses Werkzeug soll folgenden Funktionsumfang umfassen: 
- Funktion zum Erfassen des Systementwurfs, 
- Anzeigefunktionen für 

+ Aktionen, Datenelemente und Relationen zwischen diesen 

Elementen, 

+ Daten- und Steuerfluß des Systens, 

+ im System erkennbare Beziehungen der Bindungsarten, 
- Modularisierungsfunktion des beschriebenen Algorithmus, 
- Funktionen zur gezielten Auswahl von Teilsystemen, 
- Anzeigefunktion für die Elemente der modularen Struktur, 
- Bewertungsfunktionen für die modulare Struktur, 
- Menipulationsfunktionen für die modulare Struktur und 
- Analysefunktionen des Export-/Importverhaltens der Moduln. 
Mit diesem Funktionsumfang kann die Ausgangsstruktur des Systen- 
entwurfs und die erstellte modulare Struktur so lange manipuliert 
werden, bis eine den Nutzerwünschen engepaßte Zielstruktur vor- 
liegt. ö 
Für die beiden mit dem Werkzeug arbeitenden Strukturen werden 
externe Sichten vorgeschlagen, die eine effektive nutzerfreund- 
liche Arbeit sichern. Besonders die erstellten Modulbeschrei- 
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bungen müssen so aufgebaut sein, daß man sie in weiteren Soft- 


wareentwicklungsschritten anwenden kann. So bestehen z.B. An- 
schlußbedingungen, daß die Modulbeschreibungen in eine modu- 
lare Struktur einer Programmiersprache überführt werden, 
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COMPUTER. AIDED MANAGEMENT SYSTEM AT "DELEP" CONSTRUCTION 
AND CIVIL. ENGINEERING COMPANY 


Jänos-P&ter Zilahy, Deputy General Manager, "DELEP" 
Construction and Civil Engineering Company, H-6701 Szeged 


Summary 
This paper presents the main activities and organisational 


structure of the company. It gives a brief historical outline 
on the development of using computer systems in the last 20 
years at the company. It refers further on to the nowadays 
implementations in the management as well a; in the production 
scheduling and control areas. The author tries to make a short 
forcast for the near future’s ways of further development in 
this field. 


l. An Outline Profile 

DELEP is one of the largest construction companies in Hungary. 
Its annual gross production value amounts to more than 

4 billion Fts. There are 6300 persons employed,a total number 
of staff and workers, 


The annual business turnover of the company is realized in the 
following areas of Operation: 


- construction activities 62 8% lo£ which 50 % is housing 
projects/ 


- civil engineering and structural erections 8 % 

- reinforced concrete, joinery products and steel 
fabrications 30 % /of which 20 % is sold commercially/ 

- technical design and project preparation services 1 % 

.= construction abroad 2 % 


The company has multi-profile subsidiaries in Budapest and 
Bek&scsaba /with a joint staff of 1400 persons/. The mother 
company is located in Szeged. It has 3 industrial plants, 
training facilities and a hostel for workers as a number of 
administrative buildings,. 
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D 
h 


The construction activities of the company are based on 

. standard technologies, some of which are protected by patent. 
The machine fleet and the production units have been developed 
according to these standard technologles. 


The management system of the company operates at two basic 
levels: /The schematic drawing of the organization structure 


is shown in Fig.l./. 


N 


a/ Business units 
Project preparation, project control, supervision and 

accountancy are perfomed by a number of financially indepen- 

dent /so called self-accounting/ executive organisations with 

a total manpower of 4700 people. Here follows a list of these 

organisations: 

- Technical Design Office 

- Foreign Trade Office 

- Management of Installation and Finishing Works 

- Management of Building Plants 

- Management of civil Engineering Plant and Public Works 

- Management of Prefabrication Plant /Housing Factory/ 

- Supply Management " 


b/ Central organisations 


Above this level there is a central management organisation 
with a staff of 400 people who are responsible for marketing 
administration, technical development and innovation. 


The managing director has one deputy and a number of branch 
directors /technical, production, business, personnel/. The 
directors control the activities of divisions and departments 
of their own branch organisations. 
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Th: computer technology division works under the direct 
"supervision of the deputy managing director /staff: 50 people/.. 
The technical configuration available at the present time is 


described in appendix 1. 


2. The application of computer technology in the management 


activities of the company 
The company has been using computerized data processing 


techniques in its management activities since 1964. The objectives 
of employing such techniques were in each case determined by the 
current management problems of the company as well as by the 
availability of appröpriate equipment and trained personnel. 


a/ By the mid-60’s, computerized data processing was mainly used 
in the accounting and book-keeping procedures. At that time a 
batch system was used and processing was done off-site at a 
computer services centre on a BULL-GE GAMMA 115 machine. 


b/ By the end of the 60’s, the large scale housing projects 
and the growing industrial base of the company allowed for 
the application of a modified work distribution system along 
the lines of technolgical specialization. 


Based on a long-term agreement with the Institute for 
Building Economy and Organization /EGSZI/ we started to 
implement new organization and management methods at our 
company /network planning, linear production control, etc./. 
To support such new management techniques, certain areas of 
on-site and central production control received computerized 
support. The KOMPLETER software package helped us in 
establishing the time and manpower requirements of our 
construction projects, and helped us in developing 
time-tables and program schedules for each project, including 
capacity calculations and capacity utilization analysis for 
the several executive organizations. The analysis and 


e/ 


a/ 
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tne evaluation of the information provided by the computer 
took place at the central computer application department 
[Programming Department/’of our company. 


In 1971, production was started at our concrete pre-fabri- 


cation plant /with a nominal capacity of 2500 housing units 
per year/, From the very'start, we considered it important 
to co-ordinate and optimize the fabrication, transportation 
and production activities at this plant. By this time, the 
Jözsef Attila University at Szeged /JATE/ had already 
started to train computer scientists and the Hungarian 
institute for computer technology SZÄMOK ran courses for 
system designers. We employed a number of these graduated 
people and by the same time 30 persons from the staff were 
trained for using computers in a postgraduate course. 

These developments allowed us to develop our own control 
programs for concrete panel production. \ 

The system designed by our own system designers was based 
on the MINSZK-22 machine of the Szeged University. With the 
aid of this software, it was: possible to determine the 


requirements for the means of production for a given year from 


the annual construction schedules. It was also possible to 
determine the utilization of the concrete casting moulds 
[dies]. 


As the sales increased, the company expanded its capacitiy 
and in 1975, it gradually started to change its former one- 
ievel management system, developing a new two-level System 
add creating an the second level a number of independent 
operation managements. 

To follow-up these changes, the system designers now had to 
develop a computer aided management and control system which 
would define the tasks for each of these financlially 


‚independent /self-accounting/ executive divisions and 
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provide adequate information and evaluation capabilities 
concerning the particular technological processes. Our 
.company has established a computer centre in a joint 
effort with EGSZI, baskd on ES 1020 type Bulgarian 
computers /CPU 256 Kbyte/. The conceptual diagram of the 
system developed on this background is shown in Fig.2. 
The system called "DELEP INFORM" has been continuously 
expanded and developed since that time. To speed up 
implementation, the company rents a number of program 
packages and it has only developed those sub-systems in 
its own realm, which were not available in the market 
either for purchase or for renting; or sub-systems, which 
included certain elements not covered by commercially 
available packages. The various sub-systems are supported 
by common data stores but the size and capacity of the 
mainframe computer do not allow for the development and 
implementation o£ data base manipulating systems. The 
braekdown systens used for the common masterfiles are 


‚described in appendix 2. i 


During the last few years, the decline in the volume of 


state sponsored housing developments and the increasingly 
strong role of privately commissioned dwelling houses 

in the construction market necessitated further structural 
changes in our operations. First of all, we had to broaden 
the range and assortment of our pre-fabricated products. 
Because of this, production control became more compli- 
cated and, the new requirements cauld not be met by the 
software package previously used. At a competition spon- 
sored by the National Committee for Technical Development 
JOMFB/, the CentralBureau of Statistics /KSH/ and the 
Ministry for Construction and Urban. Development our company 
won a grant for the development of an "Operative Control 
System for Pre-fabricated Panel Based Housing Construction” 
- HOPIR. In. 1932, an ES lOll type /CPU 1 Mbyte/ machine 
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was put into operation at our pre-fabrication plant. 

The terminals of the system were installed at the various 
workshops and transportation check points. The terminals 

are operated by foremen. 

The logical diagram of housing construction actitivty is 
shown in Fig.3. : 

The conceptional diagram of the entire HOPIR system ailded 

by computer is shown in Figqg.A4. 

The storage space sub-system of HOPIR was first ımplemented 
in 1983, and has been in operation since then. This subsysten 
co-ordinates panel manufacturing, transportation and actüal 
assembly on a real time interactive basis. The conceptual 
diagram of the "storage-space" subsystem is shown in Figure 5. 


System outputs produced at the present period: 
On the ES-1022 machine: Quotation budgeting 


lon a computer lease basis at the 
Szeged Computer Centre of £GSZI/ 


On the ES-1020 machine: All processings of the "DELEP INFORM" 

system: 

- resource allocation against executive 
organizations 

- construction site assignment 
schedules with resource allocation 

- finished work accounting at an ana- 
lytieal, site-by-site as well as 
at an integrated level, statistical 
sheets 
- account liquiadtion, cost monitoring ,, 
- material consupmtion accounting 
- labour cost accounting 
- equipment rental fees accounting 
- output and revenue accounting 
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On tne ES-10ll machine: a]1 the processings of the HOPIR 

system: ü 

- storage space production control, 

- programming of on#site masonry and 
finishing jobs, process balancing 
“and control 

- technical preparation of production 

S - fabrication and production control 

- material storage control, container 

transportation control 


On the Commodore-64 perspnal computer: 

- technical and design applications 
le.g.: concrete mixing formulas, 
dimensions of reinforced concrete 
support elements, etc./ 

- financial applications /e.g.: finan- 
cial registers, forecasting follow-up 
evaluations, statistical computations 
etc./ 

- tender evaluation computations /e.g.: 
preparation of competitive quotations, 
quotation data base managemxant =t=./ 

- administrative applications Je.g.: 
order entry, target date registra- 
tion et./ 


The communication between the various types of machines is 
ensured by the use of magnetic tapes. 


4, Conclusions and Directions of development 


The continued recession in the construction market compels the 
construction companies to develop an increasingly competitive 
posture. The pricing system, which has hitherto been based upon 
nationally bind ing costing standars is being gradually deregu- 
lated and business depends on competitive prices adjusted 
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to production costs. The reduction of the production costs 
and the reliable and frequent analysis of the market situation 
therefore became a key to success. 


In the application of computer technology beyond the improving 
hardware and software capabilities, the human factor is seen as 
playing an increasingly important role. People must be prepared 
and trained for participating in an active and creative way in 
computer aided management and control systems. They must get 
used to the fact that their work becomes more personal, the 
structure of inter-relationhips more democratic; yet, at the 
same time what tney do will become more easily measured and 
controlled. Beyonäa formal training at schools, and specialized 
tralning after graduation, it is important to provide an 
opportunity for on-site, "live" field training, /or application 
training/ where the entire range of psychological and sociological 
motivating means must be employed. 

The application and rapid spread of personal tomputers may 

lead to the integration of certain responsibilities and functions 
/site technician, material controller, performance standard 
applicator/, and it may allow for local data processing and 
data transmission. The present administration oriented manage- 
ment structure of the company may be transformed into a project 
and profit commission oriented structure, changing the nature 
and function of data processing routines and tasks. In certain 
areas, the present processing routine will have to be substan- 
tially expanded. Among these are: quotation preparation, budget 
forecasting and computation, market analysis, market research, 
cost accounting and cost analysis. In all probability, the role 
of the small computers will be strengthened as opposed to main 
frame computers. 


Szeged, September 1984, 
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Appendix No.l. 


Technical configuration avaitable at the present time at the 
company 


Configuration of Computer Type R-11 
Hardware configuration: 


CPU 1 Mbyte 

Magnetic däisks /50 Mbyte/ 3 pcs 
Fix-headed disk /2,5 Mbyte/ l pc 
Magnetic tape units 2 pcs 
Display terminals 3 pcs 
Hardcopies /80 char./ 5 pes 
Line printer /132 char./ l pc 


Software configuration: 
MTM-2 monitor 


DMS 600 Data Base Handling System /two systems may operate 
simultaneously/ 


Configuration of computer type R-20 


Hardware configuration: 
CPU 256 Kbyte 


Card Readers 2 pcs 
Line printers /144 char. / 2 pcs 
Magnetic tape units 5 pcs 
Magnetic tape units /7,25 Mbyte/ 8 pes, 
Magnetic tape /type/ data z 
Recording posts /off line/ 5 pcs 


Main configuration of the PC’s 
PC_type Commodore-64: 

CPU 64 Kbyte 

1 display + console 

2 floppy disks /5 single page/ 
l hard copy /80 char./ 
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Appendix No 2. 


The: Code Systems used in the "DELEP INFORM" and"HOPIR" 


l. Identification of Construction Projects 
l.1 Identification of sites 


Region Code /1/ 
r—— Site identification /1-4/ 
Structure, facilities /1-5/ 
Substructure /1-6/ 
Checknumber 


SIRERE 
ENESEIENESEI EZ 


1.2 Identification of Operative Task 


Activity /l/ 


r — Subactivity /1-2/ 

—— Operation /1-3/ 
Process /1-4]/ 
Task /1-5/ 


Procedure /1-6/ 
Check number /7/ 


gıı 
ESEIEIEIEIIEI ER 


2. Identification of Organisations 
2.1 Central Organisations 


—— Management /1-2/ 
r Division /1-3/ 

Department /1-4/ 
i Section /1-5/ 


m Check number /6/ 
BESHEIEIG 
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2.2 Construction and Supply Organisations 


-— Operations management /1-2/ 
— m Project management /1-3/ 

_ Site Management /1-4/ 
Foreman /1-5/ 
Check number /6/ 


EEE 
ENESESESEI EZ 


3. Identification of Resources 
3.1 Materials 
Material class- /l/ , 


>——n Material group /1-2/ 
Material code /1-6/ 


nr Price variant /7/ 


0 7 2 Checknumber /B/ 
ılz1slalslsirlel 


3.2 Construction machines 


Amortisation class /1l 
m—— Equipment group /1-2/ 
Equipment type /1-4/ 
Equipment code /1-7/ 
Check number /8/ 


i nn 
ESEIEIENEIEZER EN 


The used codes are numerical. 


